n 



Application of Data Flow Architecture to 
Computer Music Synthesis 

by 
Carol Andrea Ccsari 



© 1981 by the Massachusetts Institute of Technology 



February 1981 



This work was supported in part by the National Science Foundation under the research grant 
MCS-7915255 



Massachusetts Institute ofTcchnology 

Laboratory for Computer Science 

Cambriclne, MA 02139 



This empty page was substituted for a 
blank page in the original document. 



Application of Data Flow Architecture to 
Computer Music Synthesis 

by 
Carol Andrea Cesari 



Submitted to the Department on Electrical Engineering and Computer Science 

on February 2, 1981 in partial fulfillment of the requirements for 

the Degrees of Bachelor of Science and Master of Science 



Abstract 



A computer music synthesis system is the most flexible of synthesis systems It offers a composer 
extensive control over the sound of his piece. A user of such a system describes his composition in 
some synthesis language. The computer uses this description to calculate samples of a voltage 
waveform that can be fed to D/A converters at a specified sampling rate. The D/As' outputs are in 
turn fed to loudspeakers that produce the sound of the user's composition. Real time performance is 
unattainable on existing computer synthesis systems due to the sequential nature of conventional 
computers. Unless the parallelism that is present in the sample calculation process is exploited, real 
time performance will remain unobtainable. This thesis presents a proposed computer synthesis 
system that includes a data flow machine, a computer whose architecture is highly parallel. The 
Music-11 synthesis system at MiT was used as a model in its design. An analysis of the algorithms 
used in the sample conversion process and how it would run on the data flow machine is presented. 
An example of how a compostion would be described in a synthesis language and how it would run 
on the proposed system is given. 
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1. Introduction 

For several decades, sound synthesis has been used in the performance of music. Though the 
sound of traditional instruments can be mimicked using sound synthesis, its major attraction for 
many composers is the opportunity it provides to create totally new an unconventional sound. 

Sound synthesis systems are the means to employ the technique of sound synthesis. Two basic 
types of sound synthesis arc hardware synthesizers and computer synthesis systems. Both follow the 
basic design shown in Fig. 1.1. They all accept a set of controls from a user as input and produce a 
voltage waveform to be fed to one or more loudspeakers. The cones in the loudspeakers vibrate 
according to the voltage waveform applied to their terminals. These vibrations produce a pressure 
waveform that is perceived as sound. The difference between the two types of systems is the 
implementation of the controls and the manner in which the voltage waveform is produced. 

1.1 Hardware Synthesizers 

Hardware synthesizers were the first synthesis systems to be built and are still in heavy use today. 
The major portion of their makeup is signal generators and modifiers that can be patched (cascaded) 
together to produce a voltage waveform. Among the list of components used are oscillators, envelope 
generators, mixers (signal adders) and filters. Suppose a composer wishes to produce the waveform: 

X(t) = A^Osinwt + A 2 (t)sin2eot 
Then the components of the synthesizer would be connected as shown in Fig. 1.2. In this example, 
the controls that the user must provide are the amplitude (in units of voltage) to the envelope 
generators and fundamental frequency to the oscillators. 

Originally the connections made between components were made through cords with plugs. 
But as synthesizer technology has progressed, a simple flick of the switch can connect two 
components in most synthesizers. The input to a component may be the output of another 
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component. It may also be a knob on the component that can be put at a constant setting or changed 
dynamically during performance by a human hand. Keyboards are generally used to control 
frequency (pitch). For example, in Fig. 1.2, the performer might input w through a keyboard with 
one hand and dynamically adjust the amplitude input to the envelope generators by turning a knob 
with the other hand. Hie duration of the note would equal the time that the key is depressed. 

It is common practice for a performer to decide what kind of sound he wishes to produce, make 
the necessary connections and then play the instrument he lias created by i sing the keyboard and 
manipulating the switches or knobs. 

The major advantage of a synthesizer is that performance takes place in real-time due to the 
nature of the hardware components. The limitations however arc apparent. If the performer wishes 
to dynamically change any other characteristics of his sound besides pitch, he must use knobs and 
switches. Since man has only two hands this can be difficult at times. 

1.2 Computer Synthesis Systems 

Most computer sound synthesis systems are some version of Fig. 1.3. A user enters a 
description of his composition in some computer language at the terminal. When he wishes to hear 
his composition, the user calls a program that takes his file as input and outputs a series of numbers 
that correspond to samples of a voltage waveform. Depending on whether the composer wishes 
mono, stereo or quadraphonic sound, samples are sent to one, two or four channels. Each channel 
contains buffer memory to hold the samples. The buffer contents arc fed at the sampling rate to D/A 
converter. The filter smooths the D/A output and produces a continuous waveform. This waveform, 
after amplification, drives the loudspeaker to produce the musical sound. 

The great advantage of such a system is the extensive control a composer has over the sound his 
piece. Details, down to the milisccohd can be specified. Also, since signal generators and modifiers 
are in the form of coded functions, many instruments of arbitrary complexity can play 
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simultaneously. The major disadvantage of computer synthesis systems is that they cannot perform 
in real time. In order to acheive real time performance, one sample of the output waveform must be 
computed every 20-30 microseconds for good quality sound. Even for a simple instrument, real time 
performance is impossible on a synthesis system similar to the one in Fig. 1.3. 

1.3 Intent of Thesis 

Real time performance is unattainable on a synthesis system similar to the one in Fig. 1.1 
because of the sequential nature of conventional computers. The conversion from the composer's 
files to samples of the output waveform is a parallel process. Unless the parallelism that is inherent in 
this conversion is exploited, real time performance is unobtainable. A computer whose architecture 
is highly parallel must be included in the system. One such computer is a data flow machine. 

The purpose of this thesis is to investigate the possibility of a synthesis system that is capable of 
real time performance, through the design of a system using a computer whose architecture is based 
on data flow principles. The major requirements of such a system arc that the system be easy for a 
composer to use and that the synthesis language be a natural way of expressing a composition. The 
flexibility and freedom of expression that presently exist in sophisticated computer synthesis systems 
should not be sacrificed. The Music-11 computer synthesis system at MIT and the Music-11 
synthesis language are used as models to help incorporate these feature into the proposed system. 

1.4 Thesis Outline 

Chapter two presents some sound synthesis techniques to give the reader a feeling of some 
principles that composer might use in the composition of his piece. Chapter three details the 
Music-11 synthesis system and synthesis language. Chapter four explains data flow concepts and the 
architecture of the data flow machine that is used in this paper. VAL, a high-level language used in 
the expression of algorithms that are to run on a data flow machine, is presented along with streams, a 



12- 



data type extension to the language. Chapter five describes the proposed real time computer 
synthesis system. An example of how the system would operate is presented in chapter six to expose 
the advantages and disadvantages of the system. Chapter six also draws some conclusions about the 
system and suggests further research. 
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2. Synthesis Techniques 

Musical sound can be described in terms of its physical attributes or its psychological attributes. 
Physical attributes include intensity, complexity (meaning the wave is not just a simple sinusoid but a 
sum of sinusoids), absorption and reverberation, resonance and modulation. These attributes can all 
be described in terms of the physical properties of the sound wave which are amplitude, frequency, 
period and phase. Psychological attributes include pitch, loudness, timbre, sound location and 
rhythm. 

There is a direct correspondence between some physical and psychological characteristics. For 
instance, pitch depends on the fundamental frequency of the sound wave and what we perceive to be 
the sound location depends on absorption and reverberation. Countcrintuitively, loudness is not a 
function of amplitude only but a function of amplitude and frequency. 

Synthesis techniques help composers to produce desired psychological sound characteristics by 
varying parameters that can be controlled, that is the wave's physical attributes. Synthesis techniques 
are an area of active research. Two of the most commonly used techniques are additive synthesis and 
FM synthesis. 



2.1 Additive Synthesis 



Additive synthesis is based on the summation of harmonically related sinusoids: 

M 
X(t) = E A k (t)sin(kw + 2wF k (t))t 

where 

X(t) = output waveform as a function of time 

u - fundamental frequency in radians 

k = harmonic number 

Aj^t) = amplitude of k" 1 harmonic as a function of time 

Fj,(t) = frequency deviation of the k*" harmonic as a function of time 
Theoretically, any waveform can be represented and hence any sound can be produced from a sum of 
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sinusoids. The problem lies in knowing which harmonics are present in a sound and also knowing 
their respective amplitudes and frequency deviations. Analysis of many different musical sounds has 
been done using filters that extract certain harmonics from a waveform. These studies have provided 
a large amount of information about different instrumental sounds. They allow us not only to 
reproduce sounds that are sometimes indistinguishable from the original but open the way to many 
new sounds. 

The result of most sound analysis is the detection of which harmonics arc present in a particular 
sound wave. Thus a big advantage of additive synthesis is that a composer can directly specify the 
harmonics in his waveform. The instrument block diagram in Kig. 1.2 is based on additive synthesis 
withM = 2. 

This popular technique is based on an equation that has been used for many years in radio 
transmission. It's use in sound synthesis was first suggested by Chowning[6]. It appears in his article 
in this form: 

X(t) = A(t)sin(at + I(t)sin^t) 



where 



Using the identity: 



X(t) = output waveform as a function of time 
A(t) = amplitude as a function of time 
o = carrier frequency in radians/sec 
fi = modulating frequency in radians/sec 
I(t) = modulation index as a function of time 



sin(0+asin<o) = jQ(a)sin0 + 
infin 

2 J k (aXsin(fl+M+(-l) k sin(0-k«)) 
k=l 



where Jj^a) = k in Besscl function at die point a, the FM equation can be expanded to: 
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X(t) = A(t){Jo(l(t))sinot 

+ J^KOXsiiKa +/8)t - sin(a-0)t] 
+ J 2 (I(t))(sin(a +20}t - sin(a -20*] 
+ ...} 

This last equation shows that wc obtain sinusoids of frequencies a, (ct±Ji), (a±.2/?), (a .±.3$) etc. As 

an example, if a = 2w*200 and /? = 2w*100 the resulting waveform will have sinusoids of 200, 

(100,300). (0,400), (-100,500) etc. Noting that sin(-w) = -sin(w), this waveform will appear to have a 

fundamental frequency of 100 cps with all harmonics present. The ampliu.dcs of these harmonics 

will depend on A(t), the index of modulation and the Bcsscl functions. 

Hie FM synthesis technique is attractive because it allows a highly complex waveform to be 

expressed in one simple equation. However FM synthesis docs not lend itself to analysis as easily as 

additive synthesis and it is difficult to develop an intuitive feel for the resulting sound. The 

modulation index determines the relative strengths of the fundamental and its partials. However if a 

composer knows which partials he would like to be present in his waveform, there is no method to 

derive an index of modulation that will produce the desired waveform. Thus, most most of the early 

studies of FM synthesis treated the FM equation empirically by plugging in different functions for 

A(t) and I(t) and listening to the results. 
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3. Music-ii Synthesis Language 

The EMS (Experimental Music Studio) facility at MIT uses a set-up much like the synthesis 
system shown in Fig. 1.3. Its processor is a DEC PDP-11/50 and the sound synthesis language is 
called Music-11. 

MusicTl, a language used for computer music composition, was developed by Barry Vercoc at 
MIT. The design of MusicTl is traditional in that it retains many of the concepts of hardware 
synthesizers. To play a composition using MusicTl, the user must create tw o files, an orchestra file 
and a score file. TTic orchestra file is a collection of instruments described in terms of oscillators, 
filters, envelope generators etc. which are functions provided by Music-11. Thus, the orchestra file 
may be likened to the components of a hardware synthesizer and the connections made among them. 

The score file is a list of notes that are to be played on each instrument. For each note the 
following information is needed: the instrument on which the note is to be played, the starting time 
of the note, the duration of the notes and several parameters that arc to be passed to the orchestra file. 
The contents of the score file are analogous to the input controls a player gives to a hardware 
synthesizer while performing. The interaction between these two files may be viewed as in Fig. 3.1. 

3.1 Orchestra File 

The orchestra file consists of a header and one or more instrument blocks. The header has the 

following format: 

sr = <int> 
kr = <int> 
ksmps = <int> 
nchnls=<m\> 

where <int> stands for any integer value. 

The variable sr is the sampling rate. This means that the DAC in Fig. 1.3 will receive a number 

of samples every second equal to sr. A signal that contains sr values for each second in time is an 
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audio signal and is said to vary at the audio rate. For good quality sound sr should be at least 30,000. 
Hardware limitations of the synthesis system impose an upper bound of 50,000. 

The variable kr is the control rate. It is a sampling rate for signals that should vary more slowly 
with time than audio signals. An example of one such signal is an amplitude envelope. 

The variable ksmps is equal to sr/kr. Because ksmps must be an integer a restriction is imposed. 
It is that srmust be divisible by kr. Also, sr, kr and ksinps must remain fixed throughout a synthesis. 

The variable nchnls specifies the number of output channels and thus the number of 
loudspeakers that are used. 

Instrument blocks are structured as follows: 

instr/j 

<body> 

endin 

where n is an integer that serves as the instrument identifier and endin signals the end of the 

instrument definition. The body is a linear sequence of statements. Several types of statements are 

available in Music-11, however only one of them, the function statement will be considered in this 

discussion. Other statement types will be introduced as they arc needed. 

Function statements arc required to have the form: 

<sig> function inpl,inp2,inp3... 

function can be one of the many signal generator or modifier function that Music-11 offers, perhaps a 
filter or an oscillator. The function's input parameters are given by inpl, inp2 and inp3. The number 
of input parameters will vary from function to function. The output of function is <sig> and with the 
exception of one function in Music-11 is either an audio or control signal. If sig is an audio signal 
then it is required to have the variable name an where « is any positive integer. If sig is a control 
signal, its variable name must be kn. 

Function statements alone can be used to express simple instrument block diagrams such as the 
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one in Fig. 1.2. Suppose it is desired that the output of die envelope generators in Fig. 1.2 be linear. 
The line function in Music-11, 

kn line ia, idur, ib 
will create such a signal. Its first and third inputs define the endpoints of a linear segment. The 
second input is the duration in seconds of the envelope. 

A sinusoidal oscillator is also needed for the instrument in Fig. 1.2 For this purpose, the 
function oscil is provided: 

an oscil xamp, xeps, ifn, iphs 

m 

It is used as an all-purpose oscillator in Music-11 and outputs samples of a periodic wave. The third 

input parameter, ifn, is an integer identifier of an array that contains one cycle of a stored function. 

These arrays are called function tables. The output of oscil is obtained by cycling through the 

function table at a frequency equal to xcps. Each function table access is multiplied by xamp. Thus 

xamp determines the amplitude. The input iphs is explained in chapter three. 

One more function is needed, the out function. The out function along with outs and outq 

specify to which speakers) the signals arc to be sent They have the following format: 

out asig 

outs asigl,asig2 

outq asigl ,asig2,asig3,asig4 

The function out is used for monophonic sound. It stipulates the signal asig is the final output signal 

for the performance, the one that should be heard and it is to be sent to one speaker. In outs, asigl 

and asig2 are the final output signals and each is to be sent to a different speaker thus producing 

stereophonic sound. The user chooses outq when quadraphonic sound is desired 

With these three functions in hand it is possible to construct a Musk -11 diagram for the 

instrument in Fig. 1.2. The Music-11 diagram is shown in Fig. $2. Its equivalent in Music-11 code 

would be: 
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endin 

Lines beginning with a semicolon arc comments. The inputs to line an.J the frequency input to 
oscil arc not directly specified in the instalment description because they are externally controlled. 
The score file provides the external control, so, p3-p7 are parameters whose values are given in the 
note statements in the score file. 

3.2 Score File 

The score file like the orchestra file has its own statement types and is only a sequence of these 

statements. The final line in a score file must always be a single e, signifying the end of the file. Thus 

the general form is: 

<statement> 
<statement> 
<statement> 



where <statemcnt> is one of several score statement types. The statement types that are needed to be 
able to write a score file to control the instrument defined in the last section are the note, stored 
function and tempo statements. 

Note statements make up the majority of the score file and hold most of the control over the 
instrument These statements follow the format: 
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\plp2p3p4p5...pI28 



where 



/;/ - identifier of instrument for which this statement is 

intended 

p2 - starting time in beats for this note 

p3 - duration of this note in beats 

p4,p5...pI28 - parameters used to control the instrument 

Though 128 parameters can be specified, only as many as the composer needs to control his 

instrument have to be included in the note statement. This is true for all score statement types. 

The stored function statement is used to create an array that holds equally spaced samples of 

one of several functions provided by Music- 1 1. Its format is: 

fplp2p3p4 p5 p6...pl28 

where 

pi - integer identifier of the function table 
p2 - creation time in beats of this function table 

p3 - the function table size (restricted to be 2 n or 2 n -l in 

Music-11) 
p4 - integer identifier of the function generator to be used 
p5,p6...pI28 • input parameters of the function generator 

An example of a function generator is one that computes one cycle of a sum of sinusoids. Its integer 

identifier is 10. The input parameters inp5, inp6... determine the relative strength of the harmonics in 

the sine wave. A user may specify up to 123 harmonics to be present in the wave. If p4 is positive 

then the wave will be scaled to a peak amplitude of 1. If/tfis negative, no scaling will take place. For 

example, 

f 1100256-104208 
causes 256 samples of one cycle of the wave 

4sinw +2sin2u + 8sin4w 
to be stored in an array and its integer identifier to be 1, whereas if the statement 
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fl 100 256 104208 
is included in the score file the same array as before is constructed and then scaled so that the 
maximum value in the array is equal to one. For both of these examples the function table will be 
generated immediately before the tenth beat of the piece is performed. 

The stored function and note statements express time in the unit of beats. Musically, this is a 
natural way to think of time progression in a composition. However the orchestra file requires that 
the unit of time for any of its inputs be seconds. The tempo statement in 'he score remedies this 
problem by giving guidelines on the beat to second conversion. The tempo statement takes the form: 

t pi p2 p3 p4 p5...pl28 

where 

pi - starting beat (restricted to equal zero) 
p2 - initial tempo in bcats/min 
p3,p5,p7...pl 27 - starting beat of next tempo 
p4,p6,p8...pJ 28 - tempos corresponding to starting beats 

It is easy to think of the input parameters as defining points on a tempo vs. beat graph. For example 

the statement, 

tO 60 10 60 20 120 

produces the graph in Fig. 3.3(a). The first ten beats are played at 60 beats/min. Between beats 10 

and 20 an accelerando from 60 to 120 bcats/min occurs. From beat 20 on, the tempo stay constant at 

120 beats/min. The last defined tempo pn in a tempo statement always remains the tempo starting at 

beat pn-1 throughout the remainder of the piece. 

The curve between beats 10 and 20 depicts how accelcrandi arc modelled. This curve is 

proportional to 1/x and is constrained by Music-11's method of beat to second conversion. Music-11 

carries out its beat to second conversion by first drawing a graph whose x coordinate is beats and 

whose y coordinate is 1 /tempo = min/beats. Such a graph for the above tempo statement example 

is shown in Fig. 3.3(b). For a given note whose beat duration occurs between beats Xj and ^ me 
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arca under the graph is computed between these two points. Since the area is in units of minutes, it is 
divided by 60 to obtain the desired unit of seconds. For example, the duration in seconds of a note 
that starts at beat 10 and is 2 beats long would be equal to the outlined area in Fig. 3.3(b) divided by 
60. 

Now all the necessary tools have been presented to assemble a score file to play the instrument 
in Fig. 3.2. A translation of the admittedly boring score in Fig. 3.4(a) is shown in Fig. 3.4(b). Lines 
beginning with c are comment lines. 

3.3 Additional Orchestra File Information 

Now that the reader is familiar with the basics of the Music-1 1 language, some additional 
information about the orchestra file is introduced. It was not presented in the previous two sections 
to avoid confusing the reader. 

3.3.1 Rates of the signal function input parameters 

As mentioned before, the output of a signal function can be cither control or audio rate. The 
input parameters of a signal function can also be different rates, but certain input parameters are 
restricted to be different rates. For instance, the oscil input parameter ifn is allowed to vary no faster 
than once each note (at the note rate). It can also be a constant, the slowest rate possible. In general 
an input parameter prefixed with an /" (ie. ifiuiphs of oscil and ia, S>, idurof line) must be ote rate or a 
constant. An input parameter prefixed with a it must vary at the control rate or a slower rate. An 
input parameter whose first letter is x (ic. xamp. xeps of oscil) is restricted to vary at the audio rate or 
a slower rate. Finally, if an input parameter is prefixed with an a (ic. asig of out) it must vary at the 
audio rate only. 
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3.3.2 Goto statements 

Goto statements belong to an orchestra statement type that was not discussed in the section in 
the orchestra file. Nevertheless, these statements arc extremely useful because they allow conditional 
branching. A goto statement may take one of die following two forms: 

goto name 
or 

if kn <tcst> km goto name 
The first goto statement causes an unconditional transfer of control to the statement whose label is 
name. The second goto statement, <test> is one of die following: =, ~ = ,>,<,>=, <=. If 
kn <test> km is true than a transfer of control to the statement labelled by name is made. Otherwise, 
the control is advanced to the next statement 

Fig. 3.5 shows an example of an orchestra file that uses goto statements. The instrument block 
models an instrument whose amplitude envelope depends on whether note's frequency is above or 
below 1000 cps. The function expon outputs a line segment with endpoints ia and ib like line except 
the line segment is exponential instead of linear. 

3.3.3 Global variables. 

All the variables in the orchestra file examples thus far have been local to the instrument block 
diat contained them. However Music-1 1 allows global variables in the orchestra file. The Music-11 
compiler recognizes a variable as global when it is prefixed by a g. An example of an orchestra file 
that uses a global variable is shown in Fig. 3.6. The signal function reverb reverberates its first input 
by a number of seconds equal to its second input. The global variable gal is used to accumulate the 
outputs of instruments 1 and 2. The sole purpose of instrument 3 is to reverberate the accumulated 
signal. 
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sr = 50000 
kr = 1000 
ksmps = 100 
nchnls = 1 

instr 1 

i!'p4>1000 then goto below 
; ia idur ib 

kl line 1000, p3, 500 

goto finish 
; ia idur ib 

below: kl cxpon 700, p3, 400 

xamp xeps ifn iphs 
finish: al oscil kl, p4, 1, -1 

out al 
endin 



EXAMPLE OF AN ORCHESTRA FILE CONTAINING GOTO STATEMENTS 



Fig. 3.5 
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sr = 50000 
kr = 500 
ksmps = 100 
nchnls = 2 

instr 1 



; xamp xcps ifn iphs 

al oscil k2, k3, 1, -1 
gal = gal 4- al 

cndin 



instr 2 



; xamp xcps ifn iphs 

al oscil k2, k3, 1, -1 
gal = gal + al 

cndin 



instr 3 

gal init 
; asig idlt 

al reverb gal, 2.49 

gal = 

outs al/2, al/2 
endin 



EXAMPLE OF AN ORCHESTRA FILE CONTAINING A GLOBAL VARIABLE 

Fig. 3.6 
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3.4 Performance 

When the user is satisfied with his files and wishes to hear them performed, he goes through a 
two step process. He must first run the program pcrf which outputs a sound file using the orchestra 
and score files as inputs. Then he must invoke the program convert with the sound file as input 

The program pcrf first processes the score by sorting it according to p2 and converting the beat 
values of p2 and p3 to seconds in agreement with the directions of the tempo statement. Then the 
orchestra and score files arc compled so they arc acceptable input to the Music-11 monitor which 
performs the actual sample calculation. The orchestra file is compilcd'into a list of function calls 
corresponding to each signal function. Each signal function has its own private data space in which to 
store the results. If the output of one function is the input of another, then the appropriate links are 
made between the two data spaces. 

The Music-11 monitor is an event-driven program that uses the score file as its event list The 
monitor's clock is initialized to zero and advances at time increments equal to one control period 
(1/kr). At the beginning of each control period, the monitor checks die score statement at the top of 
the event list to see if its clock is greater than or equal to p2. If so the monitor will act in accordance 
with the statement type. If the statement is a function statement, the monitor will create a function 
table by allocating an amount of space in memory equal to p3 and fill it with samples of the 
appropriate function. If the statement is a note statement then the note parameters pn, n>3, are read 
into the data space of the instrument specified by pi. After the monitor is done scanning the event list 
for current events, it carries out the specified function calls in the compiled orchestra file. For 
instance, for the instrument description in section 3.1, the monitor would call line and store the result, 
call oscil and store the result, call line and store the result, call oscil and store the result Finally it 
would add the outputs of the two oscil functions and write the result to a soundfilc. The out 
functions tell the monitor which signals are to be saved on the soundfilc. Thus the monitor is outputs 
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calculatcd samples of ihc uscrs's composition. 

Since the signal functions are called every control period, the functions that output control rate 
signals produce one real value and the functions that output audio rate signals produce an array of 
real values of size ksmps. 

The program convert uses the sound files as input. This program regulates the feeding of die 
buffers in Fig. 1.3 so that the samples in the sound file arc fed to the DACs at the sampling rate. 
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4. Data Flow Concepts 

It has been shown in the previous chapter that the composition language Music-11 cannot 
perform in real-time on its present processor. In fact, real-time performance of a composition written 
in any language similar to Music-1 1 is unattainable on any machine whose design adheres to the Von 
Neumann style of architecture. To realize real-time performance, a different architectural style must 
be used. One such architecture is data flow. 

Research in data flow computer architecture was initiated to develop an alternative to the Von 
Neumann architecture. Whereas the conventional Von Neumann machine must execute each 
operation in a program in sequence, a data flow machine allows many operations to be done in 
parallel increasing the computation rate and thus potentially decreasing the program execution time. 

Data flow machines are capable of high performance due to a unique architecture. An attempt 
is made in this chapter to give the reader a better than surface level understanding of the machine 
architecture that is used in this paper, present some principles of data flow and introduce VAL, a high 
level language written at MIT expressly for use with data flow machines. 

4.1 Program Graphs 

Data flow program graphs provide a useful tool in the analysis of parallelism within an 
algorithm. When an algorithm is expressed in a program graph, concurrency appears naturally. A 
brief discussion of program graphs and how they are interpreted follows. 

Figure 4.1(a) shows an example of a simple program graph. The inputs are a, b, c and d, the 
output is x. The mathematical operators enclosed by circles are called actors, the arrows are called 
arcs and die black circles are referred to as tokens. Tokens represent either elementary or structure 
values. Elementary values may be real, integer or boolean values. Structure values are compound 
data types such as arrays or records. 
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An actor may fire (perform its operation) only when all of is input arcs carry a token and its 
output arc is empty. Upon firing the actor consumes the input tokens and places a token containing 
the computed value on its output arc. The output arc may input more than one actor in which case a 
link provides the necessary number of tokens. For example, the link in Fig. 4.1(b) ensures that the 
quantity (x+y) is delivered to both the divide and multiply actors. 

Every actor abides by these firing rules except for three types of actors. They arc the merge 
actor, the T-gatc and the F-gatc (Fi >. 4.2(a,b,c)). 

The merge actor has three inputs. The inputs labelled T and F may be any value. The 
remaining value must be a boolean value. The open arrowhead shows that a boolean value is 
expected as opposed to solid arrowheads which denote non-boolean values. If the boolean input 
contains a true token and the T input contains a token then the merge actor will fire and produce a 
token containing the T input value on its output arc while absorbing the boolean and T input tokens. 
No token was needed on the F input for this to occur. If an F token did exist, it would stay there 
until a false token arrived on the boolean input In this case the actor would fire by consuming the 
boolean and F input tokens and placing a token carrying the F input value on its output arc. 

T-gatcs require two inputs, a boolean input and a non-boolean input The actor will not fire 
until both inputs are present. When the T-gate docs fire, it duplicates the non-boolean input If the 
boolean input is false the gate merely consumes the tokens and produces no output. The F-gate 
behaves in a complimentary fashion. 

Three other operations that may not be familiar to the reader are select, append and create. 
They all operate on structures. Sc\cct(struc,sel) uses the sel input to locate a value within the struc 
input. The sel input might be an index and struc input an array The output can be cither an 
elementary or structure value. Appcnd(struc,newval,scl) returns a structure exactly like the input 
struc except with newval at the place in the structure specified by sel. The operation create takes no 
inputs and returns an empty structure. Both append and select follow the firing rules. 
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4.2 Machine Architecture 

Figure 4.3 shows the architecture of the data flow machine chosen in this paper. Its design is 
similar to those in [12,9]. 

The instruction memory holds instruction blocks. Instruction blocks arc made up of instruction 
cells. An instruction cell is a block of memory and has a unique address. It is comprised of an 
opcode, and space for operands and destinations. Destinations arc addresses of instruction cells. The 
amount of space allotted to operands and destinations depends on the specific machine design. 

When an instaiction cell contains all the operands necessary to carry out the instruction 
designated by the opcode and has received a specified number of acknowledge signals, it becomes 
enabled and fires. Upon firing, an operation packet is constructed and sent through the arbitration 
network. An operation packet contains the opcode, operands and destinations. The operation packet 
is routed to the correct processor through examination of the opcode. If the opcode specifies an 
operation that accepts structures as operands then the packet is sent to the structure processor (the 
box containing SP in Fig. 4.3). Otherwise it goes to a scalar processor (the boxes containing P). The 
processor performs the operation denoted by the opcode and generates result and/or acknowledge 
packets for the destinations designated in the instruction cell. Result packets consist of the result of 
the operation and address of the instruction cell for which it is bound. Acknowledge packets contain 
an acknowledge signal and an instruction cell address. These packets are delivered to the instruction 
memory through the distribution network. 

The structure of the arbitration and distribution networks arc discussed in [12] and will not be 
detailed in this paper. The design for the structure controller used in this paper is presented in [8]. It 
contains a structure controller and structure memory as shown in Fig. 4.4. The structure controller 
interprets and carries out the operation specified in the operation packets by accessing the structure 
memory where the structures arc stored. 
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4.2.1 Instruction cell 

A closer look at the instruction cell is called for. The instruction cell design proposed by [19] 
has been adopted in this paper. Though an instruction cell is actually a block (32 bytes) of memory, it 
is more convenient to represent an instruction cell as in Fig. 4.5(a). Operation denotes the opcode 
field in the instruction cell and the three slots marked operand characterize the operand fields. The 
sections labelled data type specify whether the operand is 1 (integer), R (real), B (boolean), S 
(structure) or N (not used). A c that resides along side an operand in a slot designates that that 
operand is a constant. Constants may never be changed during the course of program execution. An 
operand slot designated to hold a constant may initially be empty at the start of program execution 
but once it is filled, it can never be written on. 

The letters m and n are integer values, m is the instantaneous number of acknowledges the 
instruction cell needs to fire during execution and n is the acknowledge reset value. After an 
instruction cell has fired, m is reset to n. Each time an acknowledge signal is received, m is 
decremented. When m is equal to zero, the instruction cell fires if all operands are present 

An instruction cell can send packets to up to six destinations (represented by the arrows). The 
six packets can be any combination of result and acknowledge packets. 

Figure 4.5(b) shows how the program graph of Fig. 4.1(b) would be translated into instruction 
cells. For each cell in this figure m is the initial number of acknowledge signals needed. The solid 
lines represent result packets while the dotted lines signify acknowledge packets. The add instruction 
cell cannot fire until it receives acknowledge signals from both the div and mul instructions cells. 
This insures that the add will not write over an operand that has not been used. The add instruction 
cell sends acknowledge signals to the cells that supplied it with its operands. The fact that n=l for 
the div and mul instruction cells implies that their results are each sent to one instruction cell. As a 
general rule of thumb, an instruction cell should acknowledge any cell from which it receives an 
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operand. However, in some cases, as we shall sec later, some acknowledge signals can be eliminated. 
Every operation that takes two operands on the flow graph level (ie. add) has the built in 
capability of a T or F gate on the instruction cell level through the use of the third operand slot. The 
third operand becomes a boolean input Result and acknowledge packets can be conditionally sent 
based on the value of the third operand. For example, when the program graph in Fig. 4.6(a) is 
translated into instruction cells (Fig. 4.6(b)), the add operator and the two gates can be expressed as 
one instruction cell. If the third operand is not used the result and acknowledge packets are sent to 
their destinations unconditionally. Whenever the third operand is used to conditionally send a result, 
two acknowledge reset values arc needed. For the add instruction cell, the true acknowledge reset 
value is / and the false acknowledge reset value is 2. If the third operand is live when the add cell 
fires, the number of acknowledges needed is set to /. Similarly, if the third operand is false when the 
cell fires, the number of acknowledges needed becomes 2. 

4.3 VAL 

Data flow program graphs are a valid tool to use in the expression of data flow algorithms, but 
writing a large program in such a graph language can be troublesome task. For this reason, the 
language VAL was written. The motivation behind the development of VAL was the need for a high 
level language in which one can write algorithms to run on a data flow machine. One of the main 
goals of VAL is to make concurrency easily identifiable. This is achieved by the exclusion of side 
effects. 

It is assumed that the reader is familiar with some block-structured language. Therefore only 
two VAL constructs will be explained that may be foreign to the reader. They are the let and for 
constructs. 
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DATA FLOW GRAPH TRANSLATION OF 
if d = then (a + b-c)* 2 else sqrt(a + b-c) + (a + b-c) 
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Fig. 4.6 
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4.3.1 LET Construct 

The let statement takes on the following form: 

let 

declaration list> 
in 

<exprcssion> 
endlct 

A declaration list is simply a list of variable declarations. In a let block, a variable may be assigned a 

i 

value only in the declaration list. Once a variable has been assigned a valu ;, no reassignment may 
take place. Thus, the declaration list, 



y : real :=3.1; 
x : real : = y/.5; 

is legal VAL code whereas, 

y : real: = 3.1; 
y:= y/.5; 

is' not acceptable VAL code. 

An expression is one or more simple expressions separated by commas. A simple expression 
for our purposes is loosely defined as VAL code that can be evaluated down to a value. This value 
may be any of the accepted data types in VAL. The arity of an expression is equal to the number of 
simple expressions it contains. For instance 4.3 and true are values and therefore expressions of arity 
one. An expression of arity two could be 5.2/8, sin(.32). 

An example of a kt statement is, 



let 






x : real : = 2.; 




y: real:- 3.1; 


fa 






x*y 



oAet 

This statement is etpaf to 6.2. 
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4.3.2 FOR construct 

For the present discussion, only a subset of possible for statements will be considered. This 
subset includes for statements that contain iteration forms. The for statement is presented by means 
of an example. 

Figure 4.7 shows a for statement that calculates x n . The declaration list, (lines 2-4) has the same 
single assignment restriction as in the let construct. However, variables declared in the for statement 
may be 



for 

factor : real : = x; 

powercount : integer : =n; 

return val : real ; = 1; 
do 

if powercount X) 

then iter 

rcturnval : = returnval*factor; 

powercount: = powercount-1; 

enditcr 

else returnval 

endif 
endfor 

Fig. 4.7 



reassigned within the iter statement. Only variables in the declaration list between the for and do 
may be reassigned. 

4.4 Translation of VAL Code to Flow Graphs 

Three examples of translating VAL code to flow graphs are given in this section. The first two 
examples are of conditional statements. The last example deals with an iteration construct 
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4.4.1 Conditionals 

Fig 4.8 shows the data flow graph for the VAL conditional statement, 

iftest_expression 

then truc_exprcssion 

else falsc_cxprcssion 
endif 

The boxes themselves contain data flow graphs. The box labelled test graph evaluates test_exprcssion 

of the conditional statement and yi' Ids a boolean value of either true or false. If it is true, the inputs 

to the t-gatcs arc allowed to feed into true graph and true_cxprcssion is evaluated. Otherwise the 

inputs to the F gates arc allowed to flow through false graph in order to evaluate false_expression. 

The number of outputs of true graph and false graph equal the arity of the conditional expression 

and must equal each other. The merge gates eliminate race conditions that may occur between die 

true and false branches of the graph. They also insure that the n*" set of outputs correspond to the 

n m set of inputs. 

As an example of a conditional statement, the reader is referred to Fig. 4.6(a) which is a flow 

graph translation of 

if d=0 

then (a+b-c)*2 

else sqrt(a+b-c)+(a+b-c) 
endif 

4.4.2 Iteration 

As an example of translating iteration constructs, Fig. 4.9 depicts the flow graph translation of 
the VAL code in Fig. 4.7. There is an initial value of false on the boolean input of the merge 
operators, to allow the inputs to drop into the iteration loops. The "XT operator outputs n 
consecutive tree values followed by one false value. Each true value allows the tokens to cycle 
around &ek respective loops one time. When the final false token is produced, Ac T-gates swallow 
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their inputs, bringing the iteration to a halt. The F-gate allows its input to pass to its output arc, to 
become the output of the graph. 

Note that after the iteration process has ended, false tokens are left on the boolean inputs of the 
merge operators. In other words, the graph will return to its initial state. This allows consecutive sets 
of tokens to flow through the graph, each set producing a correct output token. In this paper, this is a 
necessary feature of flow graphs, as shall be seen in chapter three. 

4.5 Pipelined Flow Graphs 

When algorithms arc expressed in data flow graphs, the operations that can be done in parallel 
become easily identifiable. For instance, in Fig. 4.2(b) it is clear that the add and multiply operations 
can fire simultaneously. When actors on the same level can perform their operations in parallel, there 
is horizontal concurrency. However vertical concurrency (pipelining) can also be exploited for higher 
performance. 

Every time one or more actors fires simultaneously, a tick occurs. Thus, for Fig. 4.10(a), it takes 
three ticks for the inputs x and y to help produce an output on the arc labelled z. This is because the 
depth of the graph is 3 actors. Suppose it is desired to calculate ((2*x)+y-4)/5 for many values of or 
and y. Then we can allow successive sets of x and y inputs to flow through the graph at the same time 
as shown in Fig. 4.10(a-f). Now an output is produced every other tick. When an output appears 
every second tick then the graph is maximally or optimally pipelined. 

Note that new inputs cannot be put on the graph input arcs until, the *2 and -4 operators have 
acknowledged that they have fired. Recalling the machine architecture, acknowledge packets must 
traverse the same routing networks as result packets so their transit time is the same. 

The graph in Fig. 4.11(a-f) is not maximally pipelined. This is because a new x input cannot be 
accepted until the token on the output arc of the multiplication actor has been consumed. However, 
a maximally pipelined graph can be obtained through the modification of the graph in Fig. 4.11. The 
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modiflcd graph is shown in Fig. 4.12. It contains an additional operators called identity operators. 
When an identity operator fires, it simply reproduces die input on its output arc. Thus the identity 
operator acts like a buffer in this case. ITie reader can verify that die resulting graph is maximally 
pipelined. 

In general any data flow graph that does not contain a closed padi can be maximally pipelined 
by adding enough identity operators so that every path in the graph holds the same number of actors. 
The modification of Fig. 4.11 is an example. The addition of the identity operator made the jc to / 
path two operators long to match the length of the x to s and y to / paths. 

4.6 Streams 

At this point it is useful to introduce a new data type, streams. Currently, VAL does not 
support streams. However for the purpose of this paper, streams will be used as if they exist in VAL. 
The motivation behind the inclusion of stream data type is that Music-11 instrument descriptions are 
essentially descriptions of digital signal processing networks. It is natural to think of signals as 
streams of values as they flow through networks. 

Streams are ordered sequences and can possibly be infinite. The members of a stream are 
restricted to be of the same data type, though there are no restraints on the data type. Hence there 
may be a stream of integers, a stream of arrays and even a stream of steams. 

A stream will be represented by its ordered members separated by commas, enclosed by square 
brackets. An example of a four member stream of real is x - [1.1, 2.2, 3.3, 4.4], The value 4.4 is the 
first member of the stream. A stream variable with a subscript of n denotes the n member of that 
stream. For example jr^ = 3.3. Between the last member and the left bracket of every stream there is 
an implicit eos(end of stream) value. Its use will become clear in a later section. 
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4.6.1 Stream functions 



There are seven stream functions available to the user. They are described below: 

1) first(jr) - returns the first member of stream x. 

ex.first([U.5,7D=l 
cx.nrst(Hl,3p,7J})=[Ul 

2) rest(jr) - returns the stream x without the first member 

ex. rest([l ,3,5,7])= [3,5,7] 

3) eonslO' x) - returns a stream whose last member is the 

value y and whose members before y are 
those of stream x 
ex.consKl,[3,5,7])=[3,5,7,l] 

4) cutenate(xz) - returns a stream whose members arc the 

concatenation of the members of streams 

jrand^. 

ex. append([l,3,5],[2,4]) = [1,3,5,2,4] 

5) streani_mcrge(x>'.&) - returns a stream s whose 

construction is determined by the boolean 
stream b. If the value of b R is true then s n 

is chosen from stream x otherwise it is 
chosen from stream y. Note that the sum 
of the number of members in x and the 
number of members in y must be equal to 
the number of members in b. 
ex. strcam_mcrgc([l ,3\\2]J[trueJalse, /mc]) 
= [1,2,3] 

6) stream_cxtendO(jr,.)') - returns two streams, x and y must 

be of type stream[type] where type can be 
any data type except stream. Let x be of 
length n and y be of length m. If n > m 
then x and a stream s arc returned where 
Sj = yj for i<=n-m and Sj=0 for 
i>n-m. If m >n then a streams and y are 
returned where Sy = *,- for i < =m-n and 

Sj = Ofbri>m-n. 

ex. strcam_extendO([U,3jJ5D = [1,2,31 . 
[5,0,01 

7) stream_extendt(x>') - similar to stream_extcndO except 

that the value of / instead of is used to 
extend the shorter stream. 
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Any function or operation that can be carried out on the data type of a stream's members can 

be carried out on a stream itself. When it is performed on the stream, the function or operation is 

applied to each member of the stream to produce an output stream. For the stream x= [1,9,16,81] 

some examples are given. 

\)sqrt(x)=[ 1,3,4.9] 

2)x*2=f2.18,32,162] 

3) x<20=[lrue,lrue,truejalse] 

Both operands may be streams but when they are, they must have the same number of members. As 

an example, for y=[2,4,6,8], x-y=[- 1,5,10,73] 

Streams may also be used in conditional statements, 
if iesl(z) then x else y endif 
where test is a conditional test and z, x, y are streams. The value of this conditional statement is a 
stream s. The test is performed on each member of z. If testfzj is true then s n is equal to x n and y n 
is discarded. If test(z^ is false then s is equal to y n and x is discarded. The three streams x, y and z 
must all be the same size. Streams x and y are required to have members of die same data type. 

An important property of streams is that members of a stream may be accessed before the 
stream is fully constructed. This is necessary if streams are allowed to be infinite in size. An example 
will help to clarify. The function construct_even constructs an infinite stream of consecutive even 
integers whose first member is x. The let block in Fig. 4.13 assigns the value of construc^evenfO) to y 
and produces 2*y as its value. Because of the nature of streams the multiplication starts as soon as the 
first members of y are available and will continue as long as members of y are produced. 
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function construct cvcn(x : integer returns strcani[integcr]); 

for 

outstrcam : stream! integer] '•=[]', 

x : integer := x; 
do 

if false then outstrcam 

else iter 

outstrcam := consl(outstream,x); 

x : = x + 2; 

enditer 

endif 
endfor 

endfun; 



(a) 



let 

y : streanifinteger] : = constructcven(O); 
in 

2*y 
endlct 



(b) 



Fig. 4.13 
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4.6.2 Flow graph representation of streams 

In this paper, the representation of streams in flow graphs is a sequence of tokens the last of 
which is always an eos token. So a stream multiply y*2 would be drawn as in Fig. 4.14(a). 'Hie 
" = cos" condition is to test for the cos token and prevent it from becoming a input to the multiply 
actor. The function stream_mcrge is easy to translate into a flow graph (Fig. 4.14(b)). Stream 
conditionals are also readily translated into flow graphs (Fig. 4.14(c). It is assumed that streams jc, y 
and z are all the same size. 

In order to draw graphs of stream_extendO and stream_extcndl, two new operations on the 
instruction cell level are introduced. These operations are extendO and extendi. An extendO cell (Fig. 
4.15(a)) has the following firing rules. Let the first and second inputs to the extendO cell be a and b 
respectively. If a ^ eos and b 7^ eos then a becomes the output. All acknowledge signals are sent If 
a = eos and b ?£ eos then the output is 0, the eos value remains in the first operand slot after firing 
and only acknowledge signals marked fare sent If a 7^ eos and b = eos then a becomes the output, 
the eos token stays in the second operand slot and only acknowledge signals marked t are sent. If a 
= «wand b = eos, the output is an eos token and all acknowledges are sent. The extendi instruction 
cell behaves in a similar manner except that if a = eos and b j^eos then the value 1 is the output. 

The functionstrcam_extcndO is defined on the cell graph level in Fig. 4.16(b). 
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stream merge(x,y,b) 
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Fig. 4.14 
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5. Data Flow implementation of Music synthesis 

The third chapter described a representative computer synthesis system and synthesis language, 
both named Music-11. It was shown that a computer synthesis system similar to the Music-11 system 
that allowed the modelling of reasonably complex instruments cannot perform in real time due to the 
sequential nature of conventional computers. The potential for parallel computation in the sample 
calculation process is great. One can easily see the parallelism at the level shown in Fig. 3.1. Since 
each instalment is an independent mtity, the sound outputs for each instrument can be calculated at 
the same time. Concurrency also exists in the models of each instrument in the orchestra file. For 
example if the model in Fig. 3.2 is used, the two sinusoidal components can be computed in parallel 
before summing. And yet another level of parallelism lies in the algorithms for many of the unit 
generators. A computer synthesis system could derive numerous benefits from data flow. This 
chapter describes a proposed implementation of a synthesis system that contains a data flow 
computer. This proposed system will be referred to as Music-df. 

5.1 Physical Layout of the Music-df System 

The Music-df system is envisioned to look like Fig. 5.1. The composer uses a language similar 
to Music-11 to create and edit orchestra and score files on the host computer. This computer is a 
machine whose architecture is conventional and could possibly be a PDP 11/50. When the user is 
satisfied with his files, he invokes a program that first sends the function statements of the score file 
to the data flow machine where the appropriate function tables are constructed. The orchestra file is 
compiled into executable instruction cells on the host machine and transmitted to the data flow 
machine. Then the host computer sorts the score file and carries out the beat to second conversion 
following the specifications of tempo statements in the same manner as for Music-11. After the 
sorting and orchestra file compilation have taken place, the note statements of the score file are sent 
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to the data flow machine and performance begins. 

5.2 Music-df Language 

The language that is to be used on the system will be called Music-df. It is similar to MusicTl 
and retains much of the syntax of the Music-11 language except for several changes in both the 
orchestra and score files. Some of the changes are made from necessity while others are done to 
make the files more readable and meaningful to someone other than their ct rnposer. The following 
two subsections describe the modifications that are" made to the Music-11 language to derive 
Music-df a language that will run on the Music-df system. 

5.2.1 Orchestra file modifications 

In Music-df kr and sr arc restricted to be defined as real numbers in the orchestra header. They 
must be whole numbers and as in Music-11 sr must be divisible by kr. Ksmps still must be defined as 
an integer and equal to mt(sr/kr). Unlike Music-11, kr.sr and ksmps arc available to the composer 
and can be used in expressions in the orchestra file. 

The signal naming restrictions are lifted in Music-df. Control rate signals and audio rate signals 

need not be named kn and an, respectively. The user may choose any name he wishes. This however 

may pose a problem. Consider the two fragments of Music-11 code: 

; ia idur ib 

kl line 10000, 5, 5000 

and 

; ia idur ib 

al line 10000, 5, 5000 

Even though the input parameters for line are the same in both cases, kl and al are not equivalent 

signals. They vary at different rates and are calculated differently. The Music-11 monitor knows 

which type of signal the output should be by noticing whether the first character of the output signal 
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is k or a. This naming restriction no longer exists in Music-df. So, two functions exist in Music-df, 
kline for control rate signals and aline for audio rate signals. For every function in Music-11 that can 
output cither an audio or control rate signal two corresponding functions are offered in Music-df. 
The function name is prefixed with an a or k. 

Another naming restriction that is lifted is that instrument identifiers be integers. In Music-df 
instrument identifiers are character strings. This allows an identifier to be descriptive. It is useful 
when reading an orchestra file to be able to know at a glance diat an instrument block probably 
describes a clarinet-like instrument because the instrument identifier is "clarinet". 

Since the orchestra file is to be compiled into instruction cells that run on a data flow machine 
there are two features of die Music-11 language that must be replaced. One is the tolerance of side 
effects through the use of use of global variables. An important use of side effects in Music-11 occurs 
when each instrument is to be modified in an identical manner before becoming an output. The 
global variable accumulates the output signals of all the instruments so that their sum can be 
modified instead of having to modify each one separately. Fig. 3.6 is an example where the 
modification is reverberation. It is a desirable feature to be able to accumulate the instruments' 
outputs so Music-df retains this capability by keeping global variables while excluding side effects. 

A Music-df translation of Fig. 3.6 is shown in Fig. 52. In Music-df the orchestra file is required 
to lie between a beginorchestra and an endorchestra line, making it a block in its own right A new 
statement, the output statement signals the output of die instrument block in which it is contained. In 
Music-df, the instrument block outputs may be assigned to global variables whose scope is the 
orchestra block. Global variables may be used in any instrument block but they may not be modified 
m any way within an instrument block. Now the instruments' outputs can be summed and modified 
(or not modified) as a whole before becoming the argument to an out statement The out statements 
are restricted to lie outside the instrument blocks in the orchestra block. The modification of the sum 
of the instruments' outputs may consist of several signal functions whose input parameters the 
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ksmps = 100 
nchnls = 2 
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; xamp xcps ifn iphs 
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output al 
cndin 

a2 = instrument two 

; xamp xcps ifn iphs 

al aoscil k2, k3, 1, -1 
output al 
cndin 

; asig idlt 

a3 reverb al + a2, 2.49 
outs a3/2, a3/2 

endorchestra 

MUSIC-DF ORCHESTRA FILL THAT CONTAINS GLOBAL VARIABLES 

Fig. 5.2 
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composer may wish to vary from note to note. ITiercforc the user can specify these parameters in 

score file note statements whose first parameter is out. This is a reserved instrument name. No other 

in strumen t may be called out. 

Another feature of the Music-11 orchestra file that cannot be translated into data flow is goto 

statements. The instruction cell language of a data flow machine is fundamentally different from the 

machine language of a conventional computer. In keeping with data flow principles it has no concept 

of a program counter. Therefore a goto statement is meaningless and cannot exist in data flow. The 

following conditional statement is offered in Music-df in lieu of goto statements, 

if signal! <test> signal! 
then 

<truecode> 
else 

<falsecode> 
endif 

where signal 1 and signal! may be signals of any rate and <test> is one of the following: =, ~ =,>, <, 

>=,<=. <truecode> and <falsecode> can be any legal Music-df code that can occur in instrument 

blocks. As an example, the Music-11 instrument block in Fig. 3.5 would become the following 

Music-df instrument description: 

instrument one 



if p4>1000 
then 








9 

kl 
else 


ia 
klinc 1000, 


idur 
p3, 


ib 
500 


kl 
endif 


ia 
kexpon 700, 


idur 
P3, 


ib 
400 


• 

al aoscfl 
output al 


xamp xeps 
kl, J>4, 


irh 
1, 


iphs 
-1 



The following restriction is placed on the conditional statement in Music-df. Let rate be the 
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rate (ic. audio, control, note) of signall or signatt whichever has the highest rate. Any signal 
(variable) that is defined in the conditional statement and used outside the conditional statement 
cannot have a rate slower than rale. The instrument description above adheres to this rule because kl 
is control rate and p4 is note rate. 

Finally, in Music-df once a value is assigned to a variable name it cannot be reassigned. The 
scope of a variable name introduced and defined in an instrument block is that instrument block 
alone. The scope of a variable name introduced and defined in the orchestra block but outside the 
instrument blocks is the entire orchestra file less any instrument blocks where the same variable name 
is reintroduced and defined. 

5.2.2 Score file modifications 

The only changes to the score file are that the single letter that specifies the score statement types in 
Music-11 is expanded to a word in Music-df. The letter i is replaced by note, f by functiontable, t by 
tempo and e by end. The only exception is the letter c which is continued to be used for comment 
line. As an example, note statements take the form, 

note pi p2 p3 p4...pl28 
in Music-df where pi is now a character string. 

5.3 Orchestra File Conversion 

The converted orchestra file in the data flow machine may be viewed as Fig. 5.3 where all the 
boxes contain executable instruction cells. The instrument blocks labelled instrument one and 
instrument n contains translations of the instrument descriptions in the orchestra file. Their inputs 
come from the note parameter packets sent by the host machine. The instrument outputs are then 
summed and modified using the parameters from the note statements whose first parameter is equal 
to 'out*. 
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lt is important to note that if the desired sampling rate of 50 Khz is to be achieved, the four 
output lines of the output modification box must produce a value every 20 microscc. In order for this 
to occur, the instruction cell translation of the orchestra file must be maximally pipelined. 

5.3.1 Instrument translation 

At first thought, it may seem that the instruction cell graphs in the boxes labelled instrument 

one and instrument last in Fig. 5.3 could be direct translations of die instrument blocks in the 

orchestra file. However, if they were in fact direct translations of the instrument blocks, the 

performance would not occur in the manner that the composer wishes if the score file contained rests. 

For example, consider the score, 

c instrument start duration. . . 

note one 2. . . 

note one 4 2. . . 

note one 8 2. . . 
end 

for a one instrument orchestra. If the instrument boxes in Fig. 5.3 contained direct translations of the 

instrument blocks, then three two-second notes will be played in succession. But according to the 

score there should be a two-second rest after the first and second notes. During these rests the 

instrument should remain silent The equivalent of silence is an output of zero for each sample of the 

rests' durations. Thus the instrument boxes in Fig. 5.3 must contain a control structure to ensure each 

instrument is played (or not played) at the appropriate times. 

The control structure must eventually be expressed at the instruction cell level. But it is easier 

to first describe the control structure in a high-level language (in this case, VAL) and then translate it 

into instruction cells. In order to do this, it is assumed that each instrument in the orchestra file is a 

VAL function that takes the parameters from the note statements in the score file as its input 

parameters. It is assumed that a VAL function exists for each instrument block in the orchestra file. 

These VAL instrument functions are direct translations of the orchestra file instrument blocks and 
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take the parameters from the note statements in the score file as their input parameters. The data 
type input parameters of the instrument functions is stream[rcal]. Thus the instrument functions 
accept a stream of p2, a stream of p3, a stream of p4 etc. as their inputs. The output of each 
instrument function is of type stream[strcam[rcal]] each stream in the stream of streams 
corresponding to a note in the score file. The output may be of arity one, two or four depending on 
mono, stereo or quadrophonic sound. A control structure that will accomodate rests is acheived by 
the four VAL functions in Figs. 5.4 'a-d). Since p2 and p3 in die score file note statements specify the 
starting time and duration of each note, the variable names starttime and noteduration are the 
variable names for p2 and p.? in the VAL functions of Fig. 5.4. 

The function convert_streams takes streams starttime and noteduration as inputs and outputs 
two streams. One output stream restoration contains real values corresponding to durations in 
seconds of all the rests in the score. The second stream bvat is made up of boolean values and 
determines whether the next duration is to be chosen from the stream noteduration or the stream 
resldurailon. If the next value in bval is true the next duration will be taken from noteduration, 
otherwise restduration will yield the next duration. Thus bval decides whether the next duration is an 
actual note or a rest. Taking the above score, starttitne- {0A8J and noteduration ={2,2,2J. 
Con\ertjstrcaa\s(starttime,noleduration) yields two streams restduration=[2,2] and 
6va/={true,false,true,fabe,trueJ. 

The function silence expects its input restduration to be a stream of real values whose uait is 
seconds. For each member of restduration, silence constructs a stream of zeroes. The number of 
samples in this stream is equal to the number of samples in a time duration equal to that member of 
restduration. These streams are assembled into one stream to make the strcam[streatn(rcal]] output 
that silence produces. 

The function rcpeaLbool accepts two inputs, one bval, of type streamjboolj and the other 
totattime of type strcam[realj. These streams should foe the same size. For each totahime n , a stream 
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function convertstreams(starttime,noteduration : strcam[rcal] returns 

stream[rcal],streani[bool]); 



for 



do 



endfor 
endfun 



starttimc : strcani[rcal] : = starttime; 
notcduration :strcam[rcal] : = notcduration; 
bval : stream|hool] : = [ J; 
rcstduration : strcam[real] := []; 
laststarttime : real : =0; 
lastnutcduration : real :=0; 

if starttimc = eos then rcstduration.bval 

else iter 

restduration.bval : = if laststarttime +lastnoteduration = first(noteduration) 

then cons!(bval.truc),rcstduration 

else eonsluonsl(bval,false),truc), 

consl(rcstduration,first(notcduration)-1aststarttimc-lastntotcduration) 
endif; 
laststarttime: = first(st;n ttime); 
lastnoteduration: = fir« t( notcduration); 
starttimc: = rcst(starttimc); 
notcduration: = rcst(nolcduration); 
enditer 
endif 



(a) 



function silence(restduration : stream[rcal] returns strcam[strcani[rcal]]); 
for 



do 



durations : stream[real] : = rcstduration; 
quiet : strcam[strcani[realj] : = [J; 

if durations = [ ] then quiet 

else iter 

quiet : = consl(quict,for 

quict2 : stream[rcal] : = [ ]; 

count : integer : = int(first(duralions)*kr)*ksmps; 



do 



ifcount<= 0thenquiet2 

else iter 

quict2 : = consl(quict2,0.0); 

count : = count-1; 

enditer 

endif 



endfor)) 
durations : = rest(durations); 
enditer 
endif 



endfor 
endfun 



(b) 

CONTROL STRUCTURE FUNCTIONS 

Fig. 5.4 
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function repeat bool(totaltimc : stream[real] ; bval : streamfhool] returns strcam[streant[booll]); 

for 

duration : slrcam[real] := totattime; 
decide : streamfstreamfbool)); 
bval : streanijboolj : = bval; 

if durations = [] then decide 

else iter 

decide : = eonsKdccidcfor 

dccklc2 : streaiufnool) : = [ J; 

count: integer := tnt(first(duratk)ns)*kr)*ksmps; 



do 



do 



if count < = then dee ide2 

else ker 

decidc2 : = consl(dccidc2,first(bval)); 

count := count- 1; 

cmlitcr 

endif 



endfor)) 

durations : - rest(du rations); 
bval : = rest(bval); 
enditcr 
endif 



eudfor 
endfun 



(c) 



function control(starttimc,noteduralion,p4. . .pm: streamfreal] returns stream[stream[real]); 

let 

playl,play2,play3,play4 : strcani[rcal] : = <namc>(starttime,notcdiiratk>n,p4. . .pm); 
bval.restduralion : streani|l)ool].streain[real] : = 

convert su*earns(starttimc,notcduration); 
totaltimc : strcantfrcal) : = stream mcrgc(notcduration,restduration,bval); 
quiet : streamjstreamf real|| : = silcncctrestduration); 
decide : strcani[strcam|boolJ| : = repcaVbooI(totaltime,bval); 



in 

cndlet 
endfun 



stream nierge(playl,quict, decide), stream merge( play 2,qutct,dccidc), 
stream niergc(play3,quict,dccidc),streainmcrge(pl<'iy4,qutct > dccidc) 



(d) 

CONTROL STRUC1URE FUNCTIONS 

Fig. 5.4 
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of boolean values is constructed, whose members are all equal to bval „. The size of each stream is the 
number of samples in a duration of iotaltime n . For A = [2,3], B = [trucfalse], kr= 1, ksmps= 1, 
rcpeatJ>ool(A,B) = [[true,true],[false,falsc,false]]. 

The function control (Fig. 5.4(d)) uses the output streams of convert_streams to either play the 
instrument or initiate rests. Hie function <name> is a description of the sound of the instrument 
whose identifier is <name>. The output of the function control is of arity four because the output of 
the function <name> is of arity four, signifying quadrophonic sound. 

The flow graphs for these four functions are shown in Fig. 5.5(a-d). Fig. 5.5(d) is important to 
note because it depicts what may be called the total instrument. The total instalment consists of the 
function control whose output is fed through a function destrcam. The function destrcam accepts an 
input of stream[stream[rcal]]. Its output contains all the real values present in the input except that 
its data type is stream[rcal]. The flow graph for destream is depicted in Fig. 5.5(c). In subsequent 
figures, whenever a box labelled instrument <name> appears, it replaces Fig. 5.5(d). A box labelled 
<name> represents the description of instrument <name> in the orchestra file or in other words a 
direct translation of the instrument block. 

The instruction cell graphs for conveit_streams and control are straightforward and will not be 
detailed. The cell graphs for silence and repeat_bool however bear investigation. Since these 
functions output audio rate signals they should be maximally pipelined. This means that the ">0" 
operator should output a value every other tick. A straightforward cell graph translation of these 
docs not yield optimally pipelined functions. The boxed part of Fig. 5.5(b) is where die problem lies. 
A direct translation of these cells is shown in Fig. 5.6(a). The reader can see that this graph does not 
produce an output value every other tick. Fig. 5.6(b) shows a non-direct translation tiiat is maximally 
pipelined. It is this graph portion that replaces the box labelled loop control in Fig. 5.6(a). (The loop 
control box is used in several more figures as a substitution for the four flow graph actors in Fig. 
5.5(a).) Figs. 5.7(a,b) show maximally pipelined versions of silence and repcaLbool. 
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Fig. 5.7 
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5.3.2 Instrument output summing 

The simplest implementation of the boxes labelled sum in Fig. 5.3 would be add instruction 

cells (Fig. 5.8(a)). The number of add instruction cells needed would be «-/ where n is the number of 

instruments in the orchestra file. But consider the following score file that plays a two instrument 

orchestra, 

c instrument start duration. . . 

note one 2. . . 

note one 2 4. . . 

note two 10. . . 
end 

Instrument two plays six beats longer than instrument one and thus outputs more samples than 

instrument one. If the two instruments each send their output to different speakers the piece will 

sound as it was intended to sound. However if the output of the instruments is summed before being 

sent to a speaker there is a problem. If tlic number of output samples from die instruments does not 

match up and the summing implementation in Fig. 5.8(a) is used, there will be values left in 

instruction cells after performance. Fig. 5.8(b) shows a solution to the problem. The output of the 

instrument whose output stream is shorter is extended to the Ienglft of the output stream of the other 

instrument, its new members equal to zero. The two streams are then added. If the two streams were 

to be multiplied, extendi operators would replace flie extendi operators. To sum the output of n 

instruments, each instrument's output would be destreamed and n-I of die box labelled stream sum 

in Fig. 5.8(b) would be used. 

5.33 Orchestra output modification 

The contents of the output modification box in Fig. 5.3 are shown in Fig. 5.9. The reader is 
reminded that startiime and noieduration arc equivalent to p2 and p3. Note that Fig. 5.9 assumes 
monophonic sound whereas Fig. 5.3 depicts an orchestra that outputs to four speakers. The input 
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msirumentsum is the output of a sum box in Fig. 5.3 and its type is slrc;nu[real]. If it is to be used as 
an audio rate input to a signal function in the out instrument, it must be of type streain[strcam[rcal]]. 
Therefore in instrumentsum is extended to contain a number of values equal to the number of 
samples in the total playing time of the instrument out (ic. the sum of all the p3 values). Let n2 be the 
number of members in a stream, n not necessarily equal for two arbitrary streams. Then it is required 

n-l 
that 2 p3^ for the instrument out be greater than or equal to p2 n .j+p3 n .] for any instrument 

k=0 
After instrumentsum is extended, tos tokens are inserted in the stream, the values between the eos 

tokens corresponding to the noteduration values in the score file note statements for the instrument 

out. The insertion of these eos tokens converts instrumentsum from type streamfrcal] to type 

strcani[slrcum[reul]] so that it can now become an input to the instrument out. 

If the orchestra file had four output streams (quadraphonic sound), then the boxed subgraph in 

Fig. 5.9 would be duplicated three times to accomodate the extension and data type conversion of 

four input streams. 

5.4 Signal Functions 

This section deals with the building blocks of the orchestra file, the signal functions. These 
functions can be broken down into three groups, the envelope generators, the oscillators and the 
signal modifiers. In the next three subsections, at least one example of each function type is worked 
through. For each function, VAL code is given first so that the reader can more easily understand the 
algorithm involved. The VAL code is followed by a flow graph representation and then an 
implementation using instruction cells. In deriving the instruction cell graphs, several considerations 
were taken into account 

In Music-11, each signal function is called every control period. As explained in the first 
chapter, this means that functions producing control rate signals output one real value for each 
function call and functions producing audio rate signals output an array of real values of size ksmps. 
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In Music-df, a signal function is called only once during the entire performance. Thus the output of 
each function when expressed in VAL is of type stream[stream[rcal]]. Each stream in this stream of 
streams corresponds to a note in the score file. If the output of die signal function is control rate, 
each stream in the output stream will contain int(p3*kr) real values. If the output stream is audio 
rate, each stream will consist of int(p3*kr)*ksmps. 

In Music-11 most signal functions take input signals that can be one of several rates. For 
instance in the Music-11 statement, 

an oscil xamp, xeps, ifn ,iphs 
The inputs xamp and xeps may be constants, note rate, control rate or audio rate. On the other hand, 
the signal functions in Music-df expect an input to be the highest possible rate. For example the 
xamp variable in Music-df aoscil function is expected to be audio rate. If it is not audio rate, then 
aoscil will not yield the desired output. Oftentimes, a composer would like to use a control rate signal 
as the xamp or xeps input. In order that the user not have to concern himself, it is assumed that an 
orchestra file compiler will check the inputs to the signal functions and convert them if necessary. 
For this purpose, Music-df has the following conversion functions, 

1) constant_to_control 

2) constant_to_audio 

3) note_to_control 

4) note_to_audio 

5) control_to_audio 

These functions convert a data type of the left hand side the function name to a data type of the right 

hand side of the function name. For instance, constant_to_control converts a constant number to a 

control rate stream and note_to_audio converts a note rate stream to an audio rate stream. As an 

example, for the following lines in an orchestra file, 

; ia idur ib 

ampenvelope kline p5, p3, p6 

» 

; xamp xeps ifn iphs 

sig aoscil sigl, 440, 2, -1 
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the compiler would recognize that aoscil expects its first two inputs to be audio rate. Thus 
control_to_audio(ampenvclope) and constant_to_audio(440) would become the first two inputs to 
aoscil instead of ampenvclope and 440. 

It was mentioned in section 5.2 that the orchestra file must be maximally pipelined if 
performance is to occur in real time. Thus the signal functions which are components of the 
orchestra file must also be maximally pipelined. All the signal functions are translated such that they 
output not only audio rate signals but also control rate signals every other firing to cover the 
possibility that sr = kr. All control rate and audio rate inputs to a signal function are assumed to 
arrive at the functions' input cells simultaneously and at an optimally pipelined rate. Note rate 
signals vary so slowly that that need not flow through a graph at an optimally pipelined rate. 

Finally, kr, sr and ksmps are treated as constants since they do not vary within an orchestra file. 

5.4.1 Envelope generators 

Music-U offers seven envelope generator functions. The simplest one to study but not the least 
instructive is line. This function was briefly explained in chapter one. The orchestra function 
statement for line in Music-11 takes either of the forms, 

kn line ia, idur, ib 
or 

an line ia, idur, ib 
Thus in Music-11, line can output either a control or audio rate signal. For Music-df two VAL 
functions were written, kline and aline. Both functions produce an output of type 
strcam[strcam(real]J. The output of kline is control rate and the output of aline is audio rate. The 
VAL function kline is shown in Fig. 5.10(a). In Music-df, kline needs one more input than in 
Music-11. This input is pi. This is because kline are called only once during the performance and 
needs a way of knowing how many samples to output per note. 



do 
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funclion kline(ia,idur,ib,notcduration : streamfrcal] returns streani[streani[rcal]]); 

for 

outstreams : streamfstreamjreal]] : = [ J; 
notcduraiion : strcam[rcal] : = notcduration; 
ia : streamfrcal] : = ia; 
idur : strcam[rcal] : = idur; 
ib : streainlreal] : = ib; 

if notcduration = cos then outstreams 
else iter 
outstreams : = 

consl(outstreams, 

scgment(first(ia),first(idur),first(ib),kr,int(kr*first(notcduration)))); 
notcduration : = rcst( notcduration); 
ia : = rest(ia); 
idur : = rcst(idur); 
ib : = rest(ib); 
enditer 
endif 
endfor 

endfun 



(a) 



funtion segmcnt(ia,idur,ib,rate : real; count : integer returns strcamfrcal]); 

for 

inc : real : = (ib-ia)/(idur*rate); 
y : real : = ia; 

oustream : strcamfrcal] :=[]', 
count : integer : = count; 



do 



if count >0 then iter 

outstrcam : = consl(outstream,y); 

y := y+inc; 

count : = count-1; 

enditer 

else outstream 

endif 



endfor 
endfun 



(b) 

VAL FUNCTIONS KLINE AND SEGMENT 

Fig. 5.10 
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For each member in the input streams of Mine, the function segment (Fig. 5.10(b)) is called. 
The function segment outputs samples of a linear segment whose endpoints are ia and ib. The input 
idur is the amount of time that elapses between the endpoints. The input rate determines the rate of 
the output stream. If rale=sr, the output will be audio rate and if rate- kr, the output will be control 
rate. The length of the output stream is equal to the function input count. When kline calls segment, 
count ='m\(kr*p3). This ensures that the size the segment's output stream is equal to the number of 
control samples in p3 seconds, the note duration. Note that idur docs not lwve to equal p3. It only 
serves to define the slope of the line segment. Up3<idur the segment will be tmncated and never 
reach the value ib. If pi > idur, the segment will pass the value ib and continue on the same defined 
line. 

The function aline is not shown but is similar to kline except that it calls segment with the count 
input parameter equal to mt(kr*p3)*ksmps and the rate input paramatcr equal to sr. 

The flow graph translation of kline very straightforward as shown in Fig. 5.11(a). For each 
member in the stream p3, segment constructs a stream. After the last member of stream p3 has 
travelled through the merge actor, the =eos condition will be true as the eos token appears on the 
input arc of the predicate operator. This causes an invocation of segment with a count of zero and the 
ia, ib, idur variables respectively equal to 0, 1 and 0. This is done to produce the final eos token for 
the kline strcam[strcam[real]] output 

Figs. 5.11(b) and 5.12 depict the flow graph and instruction cell translations of segment The 
function segment outputs either a control or audio rate signal and therefore line must be maximally 
pipelined. Fig 5.12 meets this requirement. The three output lines of loop-control originate from the 
same instruction cell. Acknowledge signals are left out of the figure to reduce clutter but it is 
important to note the acknowledge signals of several instruction cells so that the reader is convinced 
that Fig. 5.12 works correctly. Instruction cell 3 acknowledges cell 1 when its third input is false. It 
cannot fire until it has received an acknowledgement from the add instruction cells. Instruction cell 4 
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acknowledges cell 2 when its third operand is false. It cannot fire until it has received an 
acknowledgement from instruction cell 5. Both cells 3 and 4 acknowledge the output cell of 
loop-control. Note that cells 1, 2, and the sub and mult instruction cells do not need to be optimally 
pipelined since they fire only once per note. 

5.4.2 Oscillators 

The oscillators make up the second class of signal generators. They ouiput periodic waveforms 
and are essential to music synthesis. Without oscillators, there can be no sense of pitch to a sound. 
The oscillators in Music-11 arc table, phsor, oscil and foscil. ITie function table is not really an 
oscillator, but is included in this group because when paired with phsor, the two form an oscillator. 
Table, phsor and oscil arc discussed in the following paragraphs. 

5.4.2.1 The table functions 

A function statement in Music-11 using table looks like any of the following three statements, 

in table indx, ifn, ixqff 
kn table kndx, ifn, ixoff 
an table xndx, ifn, ixoff 

The table functions simply access the function table ifn using a real number equal to the sum of the 

ndx and /jro^inputs to linearly interpolate between two entries. 

In Music-1 1, table can output a note rate signal (the only signal function to do so), a control rate 
signal or an audio rate signal. A separate function for each rate is written in VAL. Functions itable 
and ktablc are shown in Fig. 5.13. 

The output of itable is note rate so it is of type stream[rcai]. This output stream contains one 
member for each note in the score file. Likewise, the output stream of ktablc contains one member 
for each note in the score file, but its members are control rate streams. Both itable and ktable use 
the function intcrp (Fig. 5.14(a)) to access the function table. The index input of interp is a real 



-93- 



function itablc(indx, ixofT:strcani[rcaI]; ifn : streamfarrayfrcal]] returns strcamfreal]); 

for 

index : strcamfreal] : = ndx; 

xoffsct : .strcam[rcal] : = ixofF; 

ftablc : strcam|array(rcal]] : = ifn; 

oustrcam : strcam[rcai] : = [ ]; 
do 

if index = [ ] then outstrcam 

else iter 

oustrcam := coiisl(oiitstrcam,intcrp(nrst(ftablc),first(ndx) + first(ofTsct)); 

xoffsct : = rest(offsct); 

ftablc : = rest(ftable); 

index : = rcst(indcx); 

enditer 

endif 
endfor 
endfun 

function ktab!c(ndx : streamfstrcamfreal]]; ifn : streamfarrayfrcal]]; ixoff : strcamfreal] 

returns s(ri-ani[strcam[rcai]|); 



for 



do 



endfor 
endfun 



index : strcam[streamfreall| : = ndx; 
ftablc : strcain|streamfrcal]] := ifn; 
xoffsct : strcamfreal] : = xoff; 
outstrcams : streamfstrcamfreal]] : = [ ]; 

if index = [ ] then outstrcams 

else iter 

oustreams : = consl(outstrcams,for 

indcx2 : strcamfreal] : = first(index); 

addstrcam : strcamfreal] : = f ]; 



do 



if index2 = [ ] then addstrcam 
else iter 
addstrcam : = 

consl(addstrcam,interp(first(ftablc),first(index2)+nrst(xoffset)); 
indcx2 : = rcst(indcx2); 
enditer 
endif 



endfor 

xoffsct : =rest(xoffset); 
ftablc : = rest(ftable); 
index :=rest(index); 
enditer 



VAL FUNCTIONS 1TABLE AND KTABLE 
Fig.5.D 
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number inLfrac. Interp uses frac to linearly interpolate between entries im and int+ 1. The function 
atable is not depicted but its VAL code and hence its flow graph and cell' translations are exactly the 
same as ktable. However atable expects its input stream ndx to consist of audio rate streams whereas 
the ndx input to ktable must be made up of control rate streams. Even though the VAL code for both 
is the same the user must specify his wishes by writing cither ktable or atable. 

The data flow graph for ktable (or atable) is shown in Fig. S.1S. Since interp has a depth of six 
actors (Fig. 5.14(b), the dotted lines beside the interp box must each contain six identity operators to 
insure a maximally pipelined graph. 

5.4.2.2 The phsor functions 

In Music-11 the phsor functions take the form, 

kn phsor keps, iphs 
an phsor xeps, iphs 

The phsor functions output a moving value phase where (K=phase< 1.0. This moving value 

accumulates an increment dependent on the cps input. The input iphs is a note rate stream and 

determines the initial phase value for each note. If iphs=0 then the initial phase equals 0, otherwise 

the initial phase is the value that was last calculated for the previous note. As an example, if the 

following statement is included in an orchestra file, 

; keps iphs 

kl phsor 100, 

the output signal kl will cycle from to 1 with a frequency of 100 cps. Its initial phase will always be 

0. Since kl is a control rate signal the accumulated increment will be 100/*r. In general the 

increment is equal to keps/kr (xcps/sr for an audio rate output). 

Fig. 5.16 shows the VAL function kphsor. Like all other functions that produce control rate 

signals, its output is of type strcain[strcam[rcal]]. The function rmoi(x,y) is assumed to be a built in 

operation on the data flow machine. It carries out a real (as opposed to integer) mod operation. It 
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function intcrp(ftablc : arrajjreal]; index : real returns real); 

let 

whole : integer := int(indcx); 
fraction : real : = frac(index); 



in 



endlct 
endfun; 



ftablc[\vliolc] + (ftablc[wholc+l]-ftablc[wli()lc])*fraction 
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function kphsor(kcps : stream[strcam[rcal]] ; iphs : stream[real] 

returns strcam[strcani[rcal]]); 



for 



do 



cps : strcam[strcain[rcal]] : = keps; 
phase : stream[real] : = iphs; 
outstrcams : s(rcam[strcam[rcal]] = []; 
phs : real : = 0.0; 
addstrcam : stream(real) : = [ ]; 

if amp = [ ] then outstreams 
else iter 

addstream.phs : = 
for 



do 



cps2 : streamfrcal] : = rmod(first(cps)); 

phs2: real : = if first(iphs)>= 0.0 

then first (iphs) 
else phs 
endif; 

addstrcam2 : streaiufreai] : = [ ]; 



endfor 
endfun; 



if cps2 = [ ] then addstrcam2,phs2 

else iter 

addstrcam : = consl(addstream,phs); 

phs := rmod(phs+first(cps2)/kr,1.0); 

cps2: = rcst(cps2); 

endtter 

endif 
endfor 
outstrcams := consl(outstrcams,addstream); 
cps: = rcst(cps); 
phs: = rest(phs); 
enditcr 
endif 



VAL FUNCTION KPHSOR 
Fig. 5.16 
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handles negative values of x in the following manner. rmod(-.i, 1.0)=. 7 not .3. 

The flow graph for kphsor is depicted in Fig. 5.17. The initial phase value of zero is present on 
the top left F-gate. For each stream in keps, the phase iteration section of the graph produces a 
stream of equal size. At the end of each stream kcps n , an eos token will cause the =eos condition to 
be true. The last computed phase value does not drop through die bottom F-gate into the merge 
actor but passes through the T-gate to be saved for the next iteration. If iphs n+i <0 then the saved 
phase values will be the first phase /aluc of the iteration involving kcps /J+ j. \n eos token will follow 
the last iphs member through the graph. When it becomes the input to the " = eos" actor, the actor 
will consume the eos token and place a value of true on the top T-gatc. This will allow a zero to drop 
into the phase iteration graph portion. The rmod actor will fire with the zero token as an input and 
output a zero token on the input arcs of the F- and T- gates. A final eos token from the keps stream 
of streams will cause a true token to appear on the bottom F- and T- gates. Thus the zero token will 
pass through the T-gatc and be correctly positioned to leave the graph in in its initial state. 

The kphsor flow graph is not maximally pipelined but it can be translated into a cell graph that 
is, almost (Fig. 5.18). The box labelled initial phase decide is a direct actor to cell translation from the 
flow graph. The phase iteration graph portion can easily be translated into a cell graph that can 
output tokens at the optimum rate However at the end of every iteration cycle when the last phase 
value is saved (the last phase value is the output of the rmod instruction cell when its third input is 
true), seven cells must fire in sequence (five of them in the initial phase decide subgraph) before the 
phase iteration graph can produce an output token. But this firing sequence occurs only once for 
every note in the score file. With a sampling rate of 50,000 a note would have to be less dian .001 
seconds before the output rate would be seriously impaired. 
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5.4.2.3 The oscil functions 

In Music-11, the oscil function takes the form 

kn oscil kamp, kcps, ifn, iphs 

when outputting a control rate signal and, 

an oscil xamp, xeps, ifn, iphs 

when it produces an audio rate signal. As explained in chapter one, oscil accesses samples of a 

periodic wave stored in a function table ifn at a frequency of kcps (or xips). These samples are 

multiplied by the amp input to produce the output. An example will aid the reader in understanding 

die algorithm used in obtaining the oscil output 

Consider the statement, 

kamp kcps ifn iphs 
kl koscil 10000, 440, 1, -1 

If one cycle of a smc wave is stored in function table 1, then oscil becomes a sinusoidal oscillator with 

frequency of 440 and amplitude of 10000. As explained before, oscil steps through the function 

table. But how is it determined which entry to access in function table 1? It is known that all 

function tables are of type arrayfrcal] and have limits ifn[0 : 511]. If the frequency of the signal is 

440 cycles/sec, the period is 1/440 sec/cycle, kl is a control rate signal so there are kr samples/sec 

and kr/440 samples/cycle. The table contains 512 entries/cycle, so the sampling increment should be 

(512*440)/ kr entries/sample or in general (512*cps)/#r entries/sample. In order that an illegal array 

access is not made, the accumulated increment x should not be used to read the function table but 

rmod(^512). 

The VAL function koscil calculates its array index using a method similar to the one outlined in 

the previous paragraph. The accumulated increment x is not rmod(512*cps/)fcr,512) but 

rmod(cps/#r,1.0). The function tabic index is obtained by multiplying x by 512. The calculated 

index is a real number and as in the table functions, is used to linearly interpolate between two 
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successive entries in the function table. The iphs input determines the initial entry to be accessed in 

ifn for each note. If iphs< = Q then the initial entry is zero. Otherwise the initial entry is 5l2*iphs. 

The function koscil can be defined as follows: 

function koscil(karnp,kcps:stream[strcam[rcalU; ifn :streain[array[real]); 

iphs:stream[rcal]] returns strcam[strcam[rcal]]); 

let 

phasesig:stream[strcanj[rcal]l: = kphsor(kcps,iphs); 

oscilsig:stream(strcam{a>al]]: = ktablc(phascsig*512,ifn); 
in 

kamp*oscilsig 
cndlct 

endfun 

The function kphsor is used to calculate x and ktable uses 512*x to access ifn. Since koscil is 
composed of two functions that have already been defined, its graph will not be detailed. 

5.4.3 Signal modifiers 

The third class of signal functions is the signal modifiers. The majority of these functions is a 
digital filter of some sort. The simplest of these filters is tone. 

The Music-11 format of tone is, 

an tone asig, khp, istor 
The function tone performs a low-pass filter operation on the input audio rate signal an. The 
half-power frequency of the filter is khp. The algorithm used is the filter equation, 
y[n] = bO*x[n]+al*y[n-l], where x[n] is the input corresponding to asig and bO and al are filter 
coefficients calculated from the half-power frequency by the function tonc.coeff (Fig. 5.19(b)). The 
input istor determines the initial value of y[n-l] for each note. If istor = the inital value of y[n-l] at 
the start of the next note is zero. If istotj^ the inital value of y[n-l] is the last value of y[n] from the 
previous note. 

Fig. 5.19(c) shows the VAL function tone. Tone calls the function conveit_cocff (Fig. 5.19(a)) 



do 
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function convert coefffkhp : strcani[strcam[rcal]j returns strcamlstrcam|realj|); 

for 

hp : strcamj st rcanijrcajy : =khp; 
bo : stream] s(ri:uji{rea1jj : ={ }; 
al : strcandtf reamJ*cal]J : = { J; 
sbo : st rcam|re:»tj : = { §; 
sal: strcanitrcaij : = f f ; 

ifhp = fjtfceub0,al 
else iter 
sbO,sal : = lor 

sbO : strcamjreal] : ~\ ]; 

sal : strcamfreal) :—\\, 

hp2 : real : = first{hp); 

mbO : real; 

mal : real; 
do 

M hp = J] then sbQ,sal 

else iter 

mbfl.mal : = tone cocfft;first{hp2)£ 

sbO:=c»ast(sbOviRW)); 

sal := eoasKsal.inal^ 

hp2 : = rest{hp2); 

enditer 

endif 
endfor 
bO:=con«KbO,sbO); 
al : = eoasl(a2,sal); 
hp : = rest(h.p); 
enditer 

endfor 

endfun 

VAI. FUNCnON CONVERT COEFF 
<&) 

function tone cocfUftp : real returns real); 

let 

b : real : = 2.0-eos(2*pi*flrst(hp)/sr); 

al : real : = ifhp > &Q then b-sqrt(b*b-l) else J b+sqrt(b*b-l)endil; 
in 

aU-al 



endfun 

VAL FUNC110N TONECQHFF 

Fig. 5.19 
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function tonc(asig,khp : strcam[strcam[rcal]] ; istor : stream[rcal] 

returns stream{strcain[real]); 



for 



do 



x,y : strcaiu[strcam[rcal]| := convert cocffl(khp); 
bO: slream[streani|realj] :=controho_audio(x); 
al: stream|strcam|ri'al]j := control to audio(y); 
sig : slream|strcam[rcalj] : = asig; 
stor : strcain[realj : = istor; 
result : real : - 0.0; 

outstrcams : stream(strcain[rcal]] := []; 
addoutstream : streaiii[real] := []; 

if sig = [ J then outstrcams 

else iter 

addoutstream, result : = for 

bO : streanijreal] : = first(bO); 
al : stream(real] := first(al); 
sig : stream|real| : = first(sig); 
oiiistream : slrcamfrcalj := [J; 
result : real := if firsl(istor) = 0.0 
then 0.0 
else result 
endif; 
do 

if sig = [ ] then outstrcam 

else iter 

result := first(bO)*firsl(sig) + first(al)*result; 

outstrcam : = consl(outstream,rcsult); 

b0: = rcst(b0); 

al: = rcst(al); 

sig: = rcst(sig); 

enditer 

endif 
end for 
outstrcam : = consl(oustrcams,addoutstrcam); 
b0: = rest(b0); 
al: = rest(al); 
sig: = resl(sig); 
stor: = resistor); 
enditer 
endif 



endfor 
endfun; 
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to convert the control rate stream of khp to two control rate streams of filter coefficients. The two 
streams are converted to audio rate streams by die function control_to_audio. 

The flow graph for tone is shown in Fig. 520. In order to give die reader a full understanding, 
a brief example is presented. Let asigQ = x, W Q = c, al Q = d and istor^ = 1. x, c and d are all 
streams and correspond to the first note in the score. Furthermore, let m be die length of streams x, c 
and d Because istor = 1, the initial zero token drops dirough the F-gatc and merge actor into the 
filter iteration subgraph. The initi d value of true on the input of the merge actor allows the value 
zero to rest on the input arc of the F- and T-gatcs. The condition x^=eos is false so the filter 
subgraph outputs j{0] = x q *cq. The value of jfO] is fed back through the nicrge actor in die filter 
iteration subgraph where it drops through to the F- and T-gates. If /h>1, then ){&] becomes the input 
to the multiply operator and the filter iteration subgraph outputs j(lj = xj*cj+)lQ]*dj. When 
>{/»-/] is calculated, it becomes the output of the filter iteration subgraph and is fed back to the merge 
actor where drops through to die two gates. This time, die =ara condition for x is true. Thus ){m-/l 
is swallowed by the F-gate and falls through the Tigate. The value of istorj determines whether 
){m-I] will remain the same or be assigned the value zero when computing ){*$. 

When the last note has been played, the eos token of the istor stream causes the last calculated 
output to be consumed by the F-gatc and a zero value to drop through die merge actor of the filter 
iteration subgraph. The final eos token of the asig stream of streams produces a true token on die F- 
and T-gates. Therefore die zero token passes through die T-gate and the graph is restored to its 
original state. 

The cell graph for tone is shown in Fig. 521. The filter iteration subgraph can be translated 
into an instruction cell graph that will output values at an optimum rate between consecutive false 
inputs. When the boolean input is true (when die = eos condition for asig is true), a sequence of 
seven cells must fire before die next output b produced. However, diis occurs only at the end of each 
note and docs not seriously nnpede the output rate. The box labelled idceUs, contains a sequence of 
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m identity instruction cells where in is large enough to insure that the graph is pipelined. 

5.5 Function Tables 

In Music-11 the user can create arrays and use them to store evenly spaced samples of 
waveforms. This is done by including a function statement in the score file. (The reader is referred 
to chapter one for a detailed description of the function statement.) In Music-df, the same capability 
is offered. However, instead of assigning the function generators a number that becomes p4 in the 
function statement, a meaningful name is given to each different waveform option. For instance 
function generator # 10 in Music-11 becomes sinctable in Music-df. 

All function tables arc of type array|real] and contain 513 entries. This size is considered large 
enough, particularly since all the signal functions that access function tables perform an interpolation. 
The last entry is a copy of the first entry so that an illegal array access cannot be made when a signal 
function interpolates. The array limits are [0 : 512]. 

A representative function generator, sinctable is detailed in this section. The algorithm for 
sinetable is expressed first in a VAL function and then a data flow graph. Since the instruction cell 
coding is a direct translation of the flow graph, it is not included. 

5.6 Sinusoidal Sum Function Table 

The Music-11 function generator #10 was discussed in chapter one. It computes a sum of 
sinusoids and stores them in a function table. In Music-11, a statement containing function generator 
#10 looks like, 

f pi p2 p3 10 strl, slr2, slr3,... 
where 

strl,str2,str3... - the strength of the first, second, third etc. 
partials 
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Function generator #10 in Music-11 becomes the function sinctablc in Music-df (Fig. 5.22(a)). 
It expects its input in a different format than that of Music-11. The first input strength is a stream of 
the strengths of the partials. The function sinetablc calls sinsesum (Fig. 5.22(b)) to construct an 
unsealed array and give the maximum value contained by the array. The function sinctablc then uses 
the scale input to determine whether or not to scale the sincsum's output array to a peak value of 1. 
A Music-df function statement using sinetablc has the form, 

functiontable sinctablc [strl,$tr2,str3...],xale 
The flow graphs for sinetablc and sinesum are shown in Fig. 5.23. The function sincsum 
calculates the 512 points of the waveform using the equation, 
function_table[i]: = 

strl*sin(2w/512/l*real(i))+ 
str2*sin(2w/512/2*rcal(i))+ ... 

strn*sin(2w/512/n*rcal(i)) 
Within the calculation of the contents of each table entry the VAL function sinesum computes the 
contribution of each partial in sequence. It is hoped that a compiler would be smart enough to see 
the potential for parallelism mat is not expressed in the VAL function. Consider the case where 
sinesum is called with only one partial. Fig. 5.23(b) depicts the flow graph for this case. If the 
number of partials equals n then the parallelized flow graph would be as shown in Fig. 5.23(c) where 
the number of addition operators needed would be n-1. 
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function sinctablc(strcngth : stream[real] ; scale : real returns array[real]); 
let 



in 



function tabic : array[rcal], scalcfactor : real : = sincsum(strength); 

if scale > 

then functiontable 

else 

for 

functiontable : arrayfrea] : = functiontable 

index : integer :- 0; 
do 

if index > 512 then functiontable 

else iter 

functiontablc[indcx] : = functiontabIc[indcx]/scalefactor; 

indo := index + 1; 

enditer 

endif 
endfor 
endif 



endlet 
end fun 



VAL FUNCTION SINETABLE 

(a) 

Fig. 5.22 
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function sinesum(strength :strean»{real] returns afiayfreatj); 

let 

functiontable : array[real} , max : real : = 
for 

addentry :real; 

scalcfactor : real := 0; 

count : integer : = Q; 

fUnctiotuabte : array|realj : =arrayJBB(O,-l,0>; 



Ml 



do 



if count = 512 then functiontable, scatefactor 
else iter 
addentry : =t 
for 

strength : strcajafreal} : = strength; 

x: real:— 0; 

partial :reat : = 1; 
do 

if strength = [ J then x 

etee iter 

x :=; x + first(strcngth)*sia(2*pi/512/partial*iraS(count)); 

strength : = res^strength); 

partial : = partial + 1; 

endker 

endif 
endfor 
count : =; count + 1 

functiontable: = array add,h*(functiotitable,add€Htry) 
scalcfactor : = max(sealcfactof,add«ntry); 
enditer 
endif 
endfor 

array_add,ftK^nctioritaWe,fuactiontable|(^scalelactor 

endlet 

VAL FUNCTION SINESUM 

m 

Fig. 5.22 
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beginorchcstra 










sr = 40000 










kr-5000 










ksmps = 8 










nchnls = 1 










flugclhorn = 










iastr flugclhorn 










notcfrcq = cpspch(p4) 












kamp 


irise 


idur idee 


modcnvclope 


klincn 


notcfrcq*p7, 


,06, 


p3, .02 






xamp 


xeps 


ifn iphs 


modulator 


aoscil 


modenvelope, 


notefrcq*.995, 


1, -1 






kamp 


irise 


idur idee 


ampcnvclope 


klincn 


1000*p5, 


p6, 


p3, .03 






kamp 


keps 


ifn iphs 


trcmclo 


koscil 


P9, 


p8, 


1, -1 






xamp 


xeps 


ifn iphs 


flugsound 


aoscil 


ampcnvclope*trcmclo. 


notcfrcq + modulator, 1, -1 




output 


flugsound 






cndin 










clarinet = 










instr clarinet 










notcfrcq = cpspch(p4) 








can ierfreq = 3*notefreq 








modfreq = 2*nol 


cfreq 












xamp 


irise 


idur idee 


modcnvclope 


alincn 


10000, 


.2, 


p3, 






xamp 


xeps 


ifn iphs 


modulator 


aoscil 


modcnvclope 


modfreq, 


1, o 






xamp 


irise 


idur idee 


carricrenvelopc 


alincn 


4*carrierfreq 


.2 


p3, .15 






xamp 


xeps 


ifn iphs 


clarsound 


aoscil 


carricrcnvelope, 


carricrfrcq + modulator, 1, 




output 


clarsound 






cndin 











ORCHESTRA FILE 
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pianol = 

instr pianol 
nfrcql=cpspch(p4) 
nfrcq2 = nfreql-(10/nfreql) 
nfrcq3 = nfrcql + (nfreql/200) 
if nfrcql<196 

then nfreq = nfrcq2 
else if nfrcql<784 
then nfrcq = nfreql 
else nfrcq = nfrcq3 
endif 
endif 

modlamp = (nfrcq*(8-log(nfrcq)))/(log(nfreq*(log(nfreq)) 
mod2amp=(20*(8-log(nfrcq)))/nfreq 
mod 1 freq = n frcq + ( n frcq/200) 
mod2frcq = (nl'rcq*4)+(nfi :q/200) 

ia idurl ib idur2 

1. p3*.05 .6, p3*.05, 

xamp 

mod lamp*modl freq, 

mod2amp*mod2freq, 

ampenv, 

ampenv, 

ampenv, 



;unstretccd pitch 

;strctchcd pitch for high notes 

;strctched pitch for low notes 



ampenv 



klinscg 



idur4 
p3*.25. 



modi 


aoscil 


mod2 


aoscil 


stringl 


aoscil 


string2 


aoscil 


string3 


aoscil 




output 



ie idur5 if 
.07, p3*.5, 
ifn iphs 



endin 



(stringl + string2+string3)*7000 



ic idur3 id 

.2, p3*.15, .15, 

xeps 

modi freq, 1, 

mod2freq, 1, 

nfreq + modi +mod2, 1, 

nfreq + mod 1 + mod2 + .007, 1, 

n frcq + mod l+mod2-.007 1, 



piano2 = 

instr piano2 
nfrcql = cpspch(p4) 
nfrcq2 =nfrcql-(10/nfreql) 
n frcq3 = nfrcql + (nfrcql/200) 
if nfrcql<196 

then nfreq = nfrcq2 
else if nfreql<784 
then nfreq = nfreq 1 
else nfreq = nfreq3 
endif 
endif 

modlamp = (nfrcq*(8-Iog(nfrcq)))/(log(nfreq)*(log(nfrcq» 
mod2amp = (20*(8-log(nfrcq)))/nfreq 
modi frcq = nfreq 4- (nfrcq/200) 
mod2frcq = (nfrcq*4) + (nfreq/200) 

ia idurl ib idur2 

1, p3*.05 .6, p3*.05 

xamp 

modlamp*modlfrcq, 

mod2amp*mod2frcq, 

ampenv, 

ampenv, 

ampenv, 



;unstrctched pitch 
;strctched pitch for high notes 
;strctchcd pitch for low notes 



ampenv klinscg 



modi 

mod2 

stringl 

string2 

string3 



endin 



aoscil 
aoscil 
aoscil 
aoscil 
aoscil 
output 



(stringl + string2 + string3)*7000 



ic idur3 id idur4 ie idurS if 
.2, p3M5, .15, p3*.25, .07, p3*.5, 
xeps ifn iphs 

modlfreq, 1, 

mod2frcq, 1, 

nfreq + modi +mod2, 1, 

nfreq + modi +mod2+. 007, 1, 
nfreq + mod l+mod2-.007 1, 



ORCHESTRA FILE 
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piano3 = 

iastr prano3 
pitch l=cpspch(p4) 
pitch2 = pitchl-(10/pitchl) 
pitchJ = pitch 1 + (pitch 1/200) 
if pitchl<196 

then pitch =pitch2 
else if pitchl<784 
then pitch = pitchl 
else pitch = pitclvi 
endif 
endif 

modi amp =(pitch*(8-log(pitch)))/(log(pitch)*(log(pitch)) 
mod2amp =(20*(8-log(pitch)))/pitch 
modi frcq = pitch + (pitch/200) 
mod2frcq = (pitch*4)+(pitch/200) 

ia idurl ib idur2 ic idur3 id idur4 ie 

1, p3*.05 .6, p3*.05, .2, p3*.15, .15, p3*.25. .07, 

xamp xeps 

modlamp*modlfrcq, modlfreq, 

mod2amp*mod2frcq, 

ampenv, 

ampenv, 

ampenv, 



ampenv klinscg 



modi 

mod2 

stringl 

string2 

string3 



(stringl + string2+string3)*700 



mod2frcq, 

pitch + modi + mod2, 
pitch + modi + mod2 + .007, 
pitch + modi + mod2-.007 



aoscil 
aoscil 
aoscil 
aoscil 
aoscil 
output 
endin 
pianobass= 

instr pianobass 
pitchl = cpspch(p4) 
pitch2 =pitchl-(10/pitchl) 
pitch3 = pitchl + (pitchl/200) 
if pitchl<196 

then pitch =pitch2 
else if pitchl<784 
then pitch = pitchl 
else pitch =pitch3 
endif 
endif 

modlamp=(pitch*(8-log(pitch)))/(log(pitch)*(log(pitch)) 
mod2amp = (20*(8-log(pitch)))/pitch 
mod 1 frcq = pitch 4- (pitch/200) 
mod2freq = (pilch*4)+ (pitch/200) 
; ia idurl ib idur2 k idur3 id i<.iur4 ie 

1, p3*.05 .6, p3*.05, .2, p3*.15, .15, pi*.25, .07, 
xamp xeps 

modi amp*modl frcq, modlfreq, 
mod2amp*mod2freq 
ampenv, 
ampenv, 
ampenv, 



idur5 if 
p3*.5, 
ifn iphs 
1, 
1, 
1, 
1, 
1, 



ampenv klinscg 



modi 

mod2 

stringl 

string2 

string3 



endin 



aoscil 
aoscil 
aoscil 
aoscil 
aoscil 
output 



(stringl +string2+string3)*500 



modlfreq, 

pitch + modi + mod2, 
pitch + modi + mod2 + .007, 
pitch + modi + mod2- .007 



idiirS if 

p3*.5, 
ifn iphs 
1, 
1, 
1, 
1, 
1. 



out flugclhorn + clarinet + pianol + piano2 + piano3 + pianobass 
endorchestra 
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abovc middle C. int= 8 for any note tliat lies between high C and middle C. For all other notes, .01 
is multiplied by the number of half steps it is away from the nearest C below it and added to the 
octave pitch value for that C. Therefore the octave pitch value for D above middle C is 8.02. The 
cpspch function is particularly useful when writing score files. No composer wishes to have to look 
up the cps value that corresponds to every note in his score. 

Two other functions that the reader may not be familiar with are klinen and klinseg. As can be 
seen from the flugelhorn instrument block, die inputs for klinen are kamp, irhe, idur and idee. Klinen 
first computes samples of a curve that rises linearly from to 1 in irise seconds. It remains at the 
value 1 until idur-idec seconds into the note, at which time it decays linearly back to zero in idur 
seconds. This curve is then multiplied by kamp to produce klincn's output signal. 

The function klinseg is used in the piano instrument blocks and takes the general form: 
outsig klinseg ia, idur I, ib, idurl, ic, idur3 ... 
Klinseg construct a scries of linear segments, the first having endpoints ia, ib and lasting for idurl 
seconds, the second having endpoints ib, ic and lasting for idur2 seconds, the third having endpoints 
ic, id and lasting for idur3 seconds etc. The output of the klinseg function in the piano instrument 
blocks contains five line segments. 

All three instrument blocks use the FM synthesis technique to produce their output sound. 
The flugelhorn contains a tremelo of which the depth and speed are controlled in the score file. The 
clarinet is a simple FM instrument The piano uses a doubly modulated signal for its output sound. It 
also models the fact that three strings are struck whenever a note is played and that one or more of 
these strings could be out of tune. The stringl, string2 and string3 variables represent these three 
strings. String2 and string3 are slightly off pitch. 

With an orchestra file in hand, the appropriate score file that will play the instrument can be 
written. Fig. 6.3 shows the score file that will play the instruments in the orchestra file according to 
the score in Fig. 6.1. It is important to note that whereas one usually considers a musical piece to start 
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tempo 
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= note amplitude 
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c p9 
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c 


irtstr 


start 


dur 


pith 


p5 


p6 


p7 


p8 


p9 


note 


flugclhorn 
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.75 


8.05 


10 


.2 


3 


6 


50 


note 


flugclhorn 


5.75 


.25 


8.07 


925 


.08 


5 


4 


20 


note 
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8.05 


9 
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6 
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note 
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825 
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.5 


4 


20 


note 
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7 
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6 


50 


note 


flugclhorn 


7.75 


.25 


7.09 


7.25 


.08 


.5 


4 


20 


note 


flugclhorn 


8 


1 


7.11 


7 


.15 


3 


5 


20 


note 


flugclhorn 


13 


.75 


8.05 


10 


.2 


3 


6 


50 


note 


flugclhorn 


13.75 


.25 


8.07 


9.25 


.08 


.5 


4 


20 


note 


flugclhorn 


14 


.75 


8.05 


9 
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3 


6 


50 


note 


flugclhorn 


14.75 


.25 


8.03 


8.25 


.08 


.5 


4 


20 


note 


flugelhorn 


15 


.75 


8.00 


8 


.15 


3 


5 


20 


note 


flugclhorn 


15.75 


25 


7.09 


7.25 


.08 


.5 


4 


20 


note 


flugclhorn 


16 


1 


7.11 


7 


.15 


3 


5 


20 
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c 


instr 


start 


dur 


pitch 












note 


clarinet 


1 


1 


8.05 












note 


clarinet 


2 


.5 


8.05 












note 


clarinet 


2.5 


1 


8.05 












note 


clarinet 


3.5 


1 


8.05 












note 


clarinet 


4.5 


1.5 


8.07 












note 


clarinet 


9 


1 


8.05 












note 


clarinet 


10 


5 


8.08 












note 


clarinet 


10.5 


1 


8.08 












note 
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1 


8.07 












note 


clarinet 
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1.5 


8.05 
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c piano scores 

c instr 
c right hand 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 

note pianol 

note piano2 

note piano3 
c left hand 

note pianobass 

note pianobass 

note pianobass 

note pianobass 

note pianobass 

note pianobass 

note pianobass 

note pianobass 

note pianobass 
end 



start dur pitch 



1 




8.05 


1 




8.02 


1 




7.10 


3 




8.05 


3 




8.02 


3 




7.08 


5 




8.07 


5 




8.03 


5 




7.10 


6.5 


1.5 


8.05 


6.5 


1.5 


8.03 


6.5 


1.5 


7.09 


9 




8.05 


9 




8.02 


9 




7.10 


11 




8.05 


11 




8.02 


11 




7.08 


13 




8.07 


13 




8.03 


13 




7.10 


14.5 


1.5 


8.05 


14.5 


1.5 


8.03 


14.5 


1.5 


7.09 





2 


6.10 


2 


2 


6.11 


4 


2 


7.00 


6 


2 


5.10 


8 


2 


6.10 


10 


2 


6.11 


12 


2 


7.00 


14 


1 


5.10 


15 


1 


5.10 
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on the first beat, in the notation of a Music-df score a piece starts on the zero* beat Thus the 
clarinet plays its first note on beat 1 in the Music-df score, not beat two. 

6.1.2 Performance 

With the orchestra and score files written to his satisfaction the musician would invoke a 
performance program on the host computer of the Music-df system. This program would first send 
the functiontablc statement of die score file to the data flow machine where one cycle of a sine wave 
would be stored in function table no.l. The performance program would then sort all the note 
statements in the score files in ascending order of p2. Then the p2 and p3 values would be converted 
from beat values to second values. The tempo statement in Fig. 6.3 specifics a constant tempo of 180 
beats/min. Thus all p2 and p3 values would be divided by 3. After the score file has been attended 
to, the performance program would compile the orchestra file into instruction cells and send them to 
the data flow machine. The parameters from then the note statements would then be transmitted to 
the data flow machine to play the orchestra. 

6.1 J Data flow representation of an instrument block 

Chapter five detailed how the orchestra file could be compiled. However it did not give an 
example of how the flow graph for an instrument description, (the box labelled <name> in Fig. 
5.5(d)) might be generated. Fig. 6.4 depicts the flow graph for the clarinet in the orchestra file of Fig. 
6.2. Note that the paths through which note rate signals (ie. p4) flow need not be maximally 
pipelined. However the paths of the graph through which audio rate signals flow must be maximally 
pipelined. Identity operators would have to be inserted in Fig. 6.4 on the lines labelled 1, 2 and 3 to 
ensure that all audio rate patios in the flow graph contain the same number of actors. 
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6.1.4 System Specifications 

When the orchestra file of Fig. 6.2 is compiled, it consists of 3500 instruction cells. Thus the 
instruction cell memory must contain 112,000 free bytes in which the orchestra file can reside. Of the 
3500 instruction cells fifty are structure operations. Thus it is thought that two processors are 
adequate in handling the required computation rate. One of them would of course be a structure 
processor. For a sampling rate of 40 Khz the structure processor would have to process structure 
operations at a rate of 2 Mhz. With a typical memory access time of 500 nsec this appears achievable. 
Of the remaining 3450 instruction cells containing scalar operations, 1400 take note rate signals as 
their operands. Therefore only 2050 scalar operations need to be processed every 25 microscc. A 
scalar processor with a processing rate of 85 Mhz could easily handle these operations at the desired 
speed. It would be necessary for the data flow machine to have two additional processors. One 
would be dedicated to the handling of the note statement parameter I/O. The other is required to 
manage the output of the samples to die DACs. The arbitration and distribution networks would 
have to be built so that the difference between the time from which an instruction is enabled to the 
time at which the result arrives at its destination cell is no longer than 25 microsec. 

A look at Fig. 6.1 helps to determine the demands that are set on the transmission rate of the 

note statement parameters. The worst case in terms of parameters/sec that have to be sent from the 

host to the data flow machine occurs in several places, one of them being in the second measure when 

the flugelhorn plays G natural and F natural in succesion. The section of the sorted score file that 

corresponds to these notes b: 

note flugelhorn 5.75 .25... 

note flugelhorn 6 .75... 

note pianobass 6 2... 

It is reasonable to assume that note parameters, pn: ri>\, will be sent in packets each packet 

containing the note parameter and the instrument for which it is intended.. A note parameter packet 
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might possibly contain six bytes, four for the parameter value and two for the parameter number and 
the instrument identifier. The flugelhorn instrument takes nine parameters and die pianobass 
instrument takes four parameters. Thus a total of nineteen note parameter packets must be sent in 
.25 beats or .0833 seconds. The requirement of the interface between the host computer and the data 
flow machine is that 228 note parameter packets (possibly 1368 bytes) per second be transmitted. 

6.2 Conclusion 

This thesis set out to investigate the feasibility of real time performance of a musical 
composition on a computer synthesis system. The Music-11 synthesis system and synthesis language 
were used as models in the design of a proposed Music-df system. The Music-df system uses a data 
flow machine to exploit the parallelism that exists in the performance of a composition. The previous 
section presented an orchestra and score file of medium complexity and illustrated mat real-time 
performance of these files could occur if certain design specifications of the data flow machine and its 
interface to the host computer are met 

The advantages of the Music-df system are apparent Is behavior more closely parallels that of 
a real orchestra. Once the orchestra has been loaded into the data flow machine different score files 
can be used to play it without having to recompile the orchestra. The instruction cell translation of 
the orchestra file returns to its initial state after performance. The savings in storage is large. On 
conventional computer synthesis systems, the samples of the output voltage waveform must be saved. 
For one minute of sound and a sampling rate of 40 Khz, 2.4 million real values have to be stored. 
Finally, the greatest advantage of the Music-df system from a composer's point of view is the 
relatively small turnaround time. A real time system spares the composer the annoyance of having to 
wait long periods of time to hear his composition. When he fine tunes a parameter, a composer 
would like to be able to hear a sound while the previously produced sound is still fresh in his mind. 

Whether or not the requirements of the data flow machine outlined in the last section can be 
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mct has not yet been determined due to the fact that the first data flow machine whose architecture is 
that of Fig. 4.3 is presently under construction. This machine could well forecast the future of a 
system similar to the Music-df system. 

6.3 Suggestions For Future Research 

It is easy enough to determine the required specifications for the Music-df system so that a 
given orchestra and score file can be performed in real time. However it is impractical to build a 
Music-df system for every orchestra and score file to be performed. It is much more expedient to 
construct an all purpose system that would support many different orchestra and score files. In order 
to determine what the design specifications of such a system would be, more analyses of existing 
orchestra and score files needs to be undertaken. As an example, foF the two files presented in this 
chapter, a requirement of the data flow machine was that the structure processor be able to process 
structure operations at a rate of 2 Mhz. With a typical memory access time of 500 nscc, a 2 Mhz rate 
is an upper limit of what the structure processor can handle. The structure controller of Fig. 4.4 can 
handle instructions only as fast as the structure memory will allow .it. It is not unusual for an 
orchestra file to have more oscillators than the orchestra file of Fig. 6.2, requiring a higher structure 
processing rate. It is clear that one structure memory cannot meet this requirement. The only 
solution is to have multiple instruction memories. A structure processor consisting of two structure 
memories accessed by on structure controller could deliver a 4 Mhz instruction rate provided the 
operations were evenly distributed between the two memories. The number of structure processors, 
the number of memories in each structure processor arc two of several system parameters that would 
have to be studied more carefully in the design of a more general real time synthesis system. 
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